NVIDIA/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 Kubernetes node-metadata plugin that maps each physical GPU to the closest host-visible NICs on every network rail. The feature is independent of provider.name and does not change topology.Graph. The node-data-broker discovers and publishes the record for its Node; the Node Observer creates and owns the shared ConfigMap and removes stale records. The initial rail source uses host LLDP. A future DOCA XPlane source is an extension point, not part of the initial implementation, because a supported external topology contract providing host PCI identity has not been confirmed. Motivation GPU-aware scheduling and device allocation may need more than node-to-switch topology: for every selected GPU, a consumer needs the closest NIC on each rail. This is node-local PCIe metadata and should be composable with any Kubernetes topology provider rather than implemented separately by each provider or added to the canonical topology graph. Feature implementation Responsibilitie

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