feat: Restart deployments when there are changes to config maps

[ravisoundar]

Description

Helm update to restart topograph deployment when the config map is changed.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.
• All commits are signed off per DCO (git commit -s).

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[greptile-apps]

Greptile Summary

This PR adds a checksum/config annotation to both the topograph and node-observer deployment pod templates, triggering rolling restarts whenever their respective ConfigMaps change. It follows the standard Helm pattern of hashing the rendered ConfigMap template via sha256sum and places the annotation unconditionally so it is always present regardless of whether podAnnotations are set.

• The checksum/config annotation is computed from each chart's single configmap.yml template, so changes to any value that influences those ConfigMaps (port, delay, provider, engine, trigger) will propagate to a rolling restart.
• Golden test files for all eight test scenarios have been updated with the new checksum annotation to keep the test suite in sync.

Confidence Score: 5/5

Safe to merge; the change is additive and follows the standard Helm rolling-restart pattern without touching any runtime logic.

Both deployment templates correctly hash their own configmap.yml via sha256sum, ensuring pods restart whenever managed ConfigMap content changes. The restructuring of the annotations block is valid — the checksum annotation is unconditional while user-supplied podAnnotations remain optional. Golden test files are updated and the differing checksums across test scenarios confirm the hash reflects actual value differences.

The GCP workload identity path in charts/topograph/templates/deployment.yaml is the only area where coverage could be extended if full ConfigMap tracking is desired.

Important Files Changed

Filename	Overview
charts/topograph/templates/deployment.yaml	Adds unconditional checksum/config annotation covering the primary ConfigMap; only hashes configmap.yml, so externally-referenced ConfigMaps (e.g. GCP workload identity federation credentialsConfigmap) are not tracked.
charts/topograph/charts/node-observer/templates/deployment.yaml	Adds checksum/config annotation mirroring the topograph change; node-observer's ConfigMap includes global.provider and global.engine so provider config changes will trigger restarts correctly.
tests/charts/values.yaml.golden.yaml	Golden file updated with checksum/config annotations for both node-observer and topograph deployments; checksums are stable and consistent with expected template output.
tests/charts/values.k8s.gateway-api-example.yaml.golden.yaml	Golden file updated correctly; node-observer checksum differs from base values.yaml (different provider settings), topograph checksum is stable across scenarios as expected.
tests/charts/values.k8s.gcp-federated-workload-identity-example.yaml.golden.yaml	Golden file updated correctly with scenario-specific node-observer checksum; no issues.

Sequence Diagram

sequenceDiagram
    participant User as User/CI
    participant Helm
    participant ConfigMap
    participant Deployment
    participant K8s as Kubernetes

    User->>Helm: helm upgrade (values change)
    Helm->>ConfigMap: Render + apply updated ConfigMap
    Helm->>Deployment: "Render deployment with checksum/config = sha256(configmap.yml)"
    Note over Deployment: Annotation value changed -> pod template hash differs
    Deployment->>K8s: Apply updated pod template
    K8s->>K8s: Rolling restart triggered
    K8s-->>User: Pods restarted with new config

Loading

_{Reviews (1): Last reviewed commit: "feat: Restart deployments when there are..." | Re-trigger Greptile}

[greptile-apps]

External ConfigMaps not tracked by checksum

The checksum/config annotation hashes only the internally-managed configmap.yml. The topograph deployment also mounts a second ConfigMap — the GCP workload identity federation credentialsConfigmap ($providerParams.workloadIdentityFederation.credentialsConfigmap) — which is managed outside this chart. Changes to that external ConfigMap will not change the annotation and therefore will not trigger a rolling restart. If that config can be updated independently (e.g. token audience or service account rotation), operators would need to manually trigger a restart. This is a known limitation of the single-file checksum approach and may be acceptable, but it's worth documenting.