dsx-ai-factory/topograph

Is your feature request related to a problem? Please describe. Starting a separate thread from #265 (comment) Our project runs on Kubernetes and uses NVIDIA Topograph. Each compute node may have separate IB interfaces for compute and storage, for example 4 compute IB interfaces and 1 storage IB interface. Example: Compute +-------- spine1 --------+ | | +---+----+ +----+---+ | switch1| | switch2| +---+----+ +----+---+ | | +-----+-----+ +-----+-----+ | | | | | | A B C D E F Storage +-----------------+ | switch-storage1 | +--------+--------+ | +--------------+-------------------+ | |

Description Many cloud providers expose physical topology information in their managed Kubernetes offerings through node labels. Kubernetes-native schedulers can consume these labels directly, but Slurm-on-Kubernetes systems such as Slinky require a generated topology.conf stored in a ConfigMap and cannot consume Kubernetes node labels directly. Topograph should support this use case with a dedicated provider that discovers topology from configurable Kubernetes node labels. This provider is intended to eventually supersede the existing dra provider. Proposed behavior Accept an ordered list of topology label keys, from the tier closest to the node to the furthest tier. Read the configured labels from Kubernetes Nodes and translate them into Topograph’s canonical topology graph. Treat missing or invalid label values according to a clearly defined validation policy. Integrate with the existing Node Observer so topology is regenerated when: a Node is added or deleted; a relevant topolo

Summary Add an optional, provider-independent Kubernetes node-metadata plugin that maps each discovered rail NIC to its closest physical GPU or GPUs. The SR-IOV DRA driver can consume this metadata and expose it as NIC device attributes. The feature does not depend on provider.name, change topology.Graph, or create ResourceSlice objects. Design Responsibilities Component Responsibility Node Data Broker Discover local rail and GPU/NIC topology, compute the mapping, and publish its Node record Node Observer Reconcile stale release-owned records and clean them up when the plugin is disabled Topology provider Continue producing canonical topology independently SR-IOV DRA driver Translate the mapping into attributes on the NIC devices it owns Plugin discovery and publication remain independent of provider annotation collection. Discovery and selection The initial host-lldp rail source: Runs lldpctl -f json through the host lldpd socket. Selects neighbor-bearing interfaces w

This issue is intended to discuss and align Topograph's direction - and highlight areas where contributions are especially desired! Direction Topograph's strategic positioning is to be the standard topology-discovery layer for AI cluster scheduling — a unified substrate that abstracts over diverse infrastructure sources (cloud APIs, InfiniBand fabric, NVIDIA-managed NVLink/Ethernet) and translates topology into the formats each scheduler can consume (Slurm topology.conf, Kubernetes node labels, Slinky ConfigMaps). The broader the provider and engine coverage, the more useful the standardized topology layer becomes for downstream schedulers (KAI Scheduler, Kueue, Grove, native pod affinity), operational tooling (NVSentinel), and the ecosystem of observability / placement tools that depend on accurate, real-time topology data. We actively welcome community contribution. The provider interface is well-defined, the engine boundary is stable, and the project is designed to accept new inte

Problem docs/engines/k8s.md currently ends with: Validation and Testing TBD Topograph has Go unit tests and integration fixtures (tests/integration/payloads/*.json), but no end-to-end cluster-level suite that asserts "given a deployed chart, do the right labels and annotations actually land on nodes?" This gap is felt most acutely when changing the Helm chart, Node Observer, or engine output — there's no quick way to verify the full deployment-to-labels flow without manual cluster testing. Proposed approach Adopt Chainsaw (Kyverno team, Apache 2.0) — the declarative Kubernetes E2E test framework used widely across Kubernetes OSS. Tests are YAML that run apply → wait → assert → cleanup against a real cluster (kind in CI). Assertions use JMESPath-style expressions to verify cluster state, which fits Topograph's output model precisely: node labels, annotations, and ConfigMaps are exactly what Chainsaw is designed to assert. Why Chainsaw specifically: Topograph's Kubernetes en