Skip to content

NVIDIA/nv-config-manager

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

13 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

NVIDIA Config Manager

NVIDIA Config Manager is an open-source network automation and configuration management platform for large-scale datacenter operations. It combines Nautobot inventory, event-driven rendering, ZTP, DHCP, workflow automation, and configuration storage behind a single Helm deployment.

Overview

Service Description
ZTP Zero Touch Provisioning, boot scripts, OS image delivery, and provisioning status updates
DHCP Kea DHCP configuration generation from Nautobot data
Temporal Long-running network operations and approval workflows
Render Template rendering and event processing from Nautobot and workflow events
Config Store PostgreSQL-backed rendered, intended, and backup configuration storage
UI React/Next.js interface for workflows and configuration browsing
Nautobot Network source of truth, custom jobs, and event publication

Installer

The NVIDIA Config Manager Installer is the supported deployment entry point. It provides an interactive TUI and a headless CLI that both use the same nv-config-manager-install.yaml configuration file.

cd installer
uv sync
uv run nv-config-manager-installer init

Common non-interactive commands:

cd installer
uv run nv-config-manager-installer validate ../deploy/configs/local-superpod.yaml
uv run nv-config-manager-installer generate-values ../deploy/configs/local-superpod.yaml --output-dir ../generated
uv run nv-config-manager-installer deploy ../deploy/configs/local-superpod.yaml \
  --image-source local \
  --build-images \
  --load-kind \
  --kind-cluster nv-config-manager \
  --install-envoy-gateway \
  --install-cnpg-operator \
  --install-cert-manager

The installer handles Helm values generation, Kubernetes secrets, optional operator installation, image builds, Kind image loading, content PVC staging, ZTP OS image staging, post-deploy Nautobot jobs, and endpoint reporting.

Local Development Setup

Install project tools and dependencies before running tests or local deployments.

curl -LsSf https://astral.sh/uv/install.sh | sh
uv sync --dev
./scripts/install-hooks.sh

For UI work:

cd ui
npm install

Validation commands:

uv run pytest
uv run ruff check src/
uv run mypy src/
uv run ruff format src/

Kubernetes Deployment

Prerequisites:

  • Docker or a compatible container runtime
  • Kind for local clusters, or a reachable Kubernetes cluster
  • Helm 3.x
  • kubectl configured for the target cluster
  • Python 3.11 or newer, managed through uv
  • Node.js 23 or newer for UI development

Resource Profiles

Resource sizing is selected in installer config at cluster.size.

Size Environment Suggested Capacity Notes
small Local laptop or CI 8 vCPU, 24 GB RAM Single replica development profile
medium Remote VM or staging 16 vCPU, 64 GB RAM Larger requests for a shared development VM
large Production 96 vCPU, 256 GB RAM, 3+ nodes HA-oriented replica counts and resource requests

The bundled profiles in deploy/configs/ are ready-to-run examples. Override the selected profile with cluster.size in a copied installer config.

Local Kind Deployment

make kind-up

The default make kind-up target creates the Kind cluster if needed, builds local images, loads them into Kind, installs required operators, and deploys using deploy/configs/local-superpod.yaml.

Populate or refresh mock topology data:

make topology

Local Hostnames

The local SuperPOD profile uses config-manager.local as the base hostname. Add these entries when accessing the Envoy Gateway directly from your workstation:

127.0.0.1 config-manager.local
127.0.0.1 nautobot.config-manager.local
127.0.0.1 render.config-manager.local
127.0.0.1 ztp.config-manager.local
127.0.0.1 dhcp.config-manager.local
127.0.0.1 workflow.config-manager.local
127.0.0.1 config-store.config-manager.local
127.0.0.1 temporal.config-manager.local
127.0.0.1 svc-workflow.config-manager.local
127.0.0.1 svc-config-store.config-manager.local
127.0.0.1 svc-render.config-manager.local
127.0.0.1 svc-ztp.config-manager.local
127.0.0.1 svc-dhcp.config-manager.local
127.0.0.1 svc-nautobot.config-manager.local

Local endpoints:

For the local SuperPOD profile, Nautobot login is admin / admin. For generated credentials:

kubectl get secret nautobot-admin -n nv-config-manager -o jsonpath='{.data.password}' | base64 -d && echo
kubectl get secret nautobot-admin -n nv-config-manager -o jsonpath='{.data.api_token}' | base64 -d && echo

Makefile Commands

make kind-up                  # Create a Kind cluster and deploy the platform
make kind-up-with-topology    # Alias for kind-up when the config runs topology jobs
make topology                 # Run configured mock topology jobs against an existing deployment
make kind-down                # Delete the Kind cluster
make local-up                 # Deploy to the current Kubernetes context
make local-down               # Remove the Helm release and namespace
make local-status             # Show pods, services, and gateway state
make local-logs               # Tail deployment logs
make port-forward             # Forward Nautobot and Temporal UI locally
make docker-build             # Build all local container images
make test                     # Run Python tests
make lint                     # Run Python linters and type checks
make openapi                  # Regenerate OpenAPI specs
make openapi-check            # Check OpenAPI specs are current
make docs-lint                # Lint documentation markdown
make docs-lint-fern           # Validate Fern docs configuration

Air-Gapped Deployment

Air-gapped bundles are built from deploy/airgapped/create-airgapped.sh. The bundle contains the Helm chart, container images, dependency charts and manifests, image loader manifests, operator version pins, the offline installer package, and an OCI registry upload helper.

On an internet-connected build host:

cd deploy/airgapped
export NGC_API_KEY="your-ngc-api-key"
./create-airgapped.sh --version v1.0.0 --arch amd64

On the target environment, upload the images and packaged chart to an OCI-compliant registry first:

tar -xzf nv-config-manager-airgapped-v1.0.0-amd64.tar.gz
cd nv-config-manager-airgapped-v1.0.0-amd64
./upload-to-registry.sh \
  --registry registry.example.com/nv-config-manager \
  --chart-registry registry.example.com/nv-config-manager/charts \
  --username '<user>' \
  --password-stdin

Then install from the bundled chart and offline installer:

./installer/install.sh
./installer/nv-config-manager-installer init --config install.yaml
./installer/nv-config-manager-installer deploy install.yaml \
  --chart-dir helm \
  --image-source registry \
  --install-envoy-gateway \
  --install-cert-manager \
  --install-cnpg-operator

For demos or clusters without a registry, preload image tarballs onto the target nodes instead:

./manifests/load-airgapped-images.sh ./images --daemonset

See Air-Gapped Installation for the full offline workflow.

Repository Structure

nv-config-manager/
├── src/nv_config_manager/       # Python services and shared libraries
├── src/tests/                   # Python test suites
├── ui/                          # React/Next.js UI
├── components/                  # Nautobot image assets and helper containers
├── development/mock_topology/   # Local development topology job data
├── installer/                   # Interactive and headless installer package
├── deploy/helm/                 # Helm chart and values overlays
├── deploy/airgapped/            # Offline bundle tooling
├── docs/                        # Fern documentation site and generated API specs
├── build/                       # Dockerfiles
├── db/                          # Alembic migrations
├── Makefile                     # Development commands
└── pyproject.toml               # Python project configuration

Service Architecture

Envoy Gateway / Ingress
  |-- UI
  |-- Nautobot
  |-- Workflow API and Temporal UI
  |-- Render API
  |-- Config Store API
  |-- ZTP and DHCP device-facing services

Nautobot -- NATS JetStream --> Render and workflow consumers
Render --> Config Store
ZTP and DHCP --> Nautobot and Config Store
Temporal workers --> Nautobot, Render, Config Store, and managed devices

Testing

make test
make test-cov
uv run pytest src/tests/ztp/
uv run pytest src/tests/temporal/
uv run pytest src/tests/render/
make lint
make format

Integration tests require a running deployment:

make test-integration
uv run pytest src/tests/integration/ -v \
  --nv-config-manager-namespace nv-config-manager \
  --base-hostname config-manager.local

With real OIDC authentication:

uv run pytest src/tests/integration/ -v \
  --base-hostname qa.config-manager.example.com \
  --sso

Configuration

Runtime service configuration is delivered through the nv-config-manager-ini Kubernetes secret. The installer generates the secret content from nv-config-manager-install.yaml, selected size profile overlays, and generated or user-supplied secrets.

OpenAPI specs live in docs/api-specs. Run make openapi-check before changing API handlers.

Releases and Roadmap

  • Release notes are tracked in CHANGELOG.md.
  • Release tags are promoted through protected release workflows in .github/workflows/.
  • Roadmap and planning details are tracked through project issues and maintainer planning until a public roadmap is published.

Authentication

The shared nv_config_manager.common.auth.OIDCAuth helper implements browser-based OIDC PKCE for CLIs, tests, scripts, and notebooks.

from nv_config_manager.common.auth import OIDCAuth

auth = OIDCAuth.discover_from_gateway(
    "https://workflow.qa.config-manager.example.com/whoami",
    verify=False,
)
token = auth.get_access_token()

The svc-* hostnames, such as svc-workflow.<base-hostname>, accept bearer tokens directly and are intended for CLI and machine access.

Component Documentation

External Dependencies

These packages are published separately:

  • nv-config-manager-templates: Network configuration Jinja2 templates
  • nautobot-plugin-nv-config-manager: Nautobot plugin for NVIDIA Config Manager integration
  • nautobot-broker-nats: NATS event broker for Nautobot

Contributing

Start with CONTRIBUTING.md. Contributions must follow the Developer Certificate of Origin sign-off process described there.

  1. Fork the repository.
  2. Create a feature branch.
  3. Make changes.
  4. Run tests and linting with make test lint.
  5. Submit a pull request using the repository PR template.

Please also follow the Code of Conduct.

Governance and Maintainers

Security

Do not report security vulnerabilities through public GitHub issues. Follow the private disclosure process in SECURITY.md.

Citation

Citation guidance is available in CITATION.md.

License

NVIDIA Config Manager is licensed under Apache 2.0. See NOTICE for attribution notices.

About

NVIDIA Config Manager

Resources

License

Code of conduct

Contributing

Security policy

Stars

Watchers

Forks

Packages

 
 
 

Contributors