Skip to content

feat(installer): stamp provenance labels on installer-managed resources#25

Open
dmathur0 wants to merge 2 commits into
mainfrom
port/installer-provenance-labels
Open

feat(installer): stamp provenance labels on installer-managed resources#25
dmathur0 wants to merge 2 commits into
mainfrom
port/installer-provenance-labels

Conversation

@dmathur0

@dmathur0 dmathur0 commented Jun 2, 2026

Copy link
Copy Markdown
Collaborator

Stamp a consistent set of app.kubernetes.io/* labels plus a nv-config-manager.nvidia.com/installer-version annotation onto every resource the installer creates directly via the Kubernetes API (namespaces, secrets, PVCs, loader pods), and push the same installer marker onto operator Helm releases via each chart's commonLabels value. Operator namespaces are pre-created so they carry the labels instead of being lazily created unlabelled by --create-namespace. This makes installer-managed objects discoverable for cleanup with simple label selectors.

Description

Validation

  • Standard CI passes.
  • Kind integration passes, or this PR explains why it was not run.

The kind integration test is manual due to taking ~30 min to complete. When the PR is ready for review,
run Actions -> Kind Integration -> Run workflow against the copy-pr-bot generated
pull-request/<PR_NUMBER> branch. Use the default test_path for the full suite,
or narrow it only while debugging.

Passing Kind Integration run:

Checklist

  • I am familiar with the contributing guidelines in CONTRIBUTING.md.
  • Commits are signed off for DCO compliance.
  • New or existing tests cover these changes, or the PR explains why tests are not needed.
  • Documentation is updated for user-facing behavior changes.
  • Generated artifacts are updated when applicable, such as OpenAPI specs,
    docs screenshots, or Helm/rendered outputs.

Summary by CodeRabbit

  • New Features
    • Installer now tags created Kubernetes resources with consistent provenance labels and an installer-version annotation.
    • Operator namespaces are pre-created and carry installer provenance labels for consistent ownership.
    • Helm-based installs now propagate installer provenance to charts and CRDs using chart-appropriate mechanisms (chart labels, pod labels, or CRD annotations) so installed components show installer metadata.

Stamp a consistent set of app.kubernetes.io/* labels plus a
nv-config-manager.nvidia.com/installer-version annotation onto every
resource the installer creates directly via the Kubernetes API
(namespaces, secrets, PVCs, loader pods), and push the same
installer marker onto operator Helm releases via each chart's
commonLabels value. Operator namespaces are pre-created so they carry
the labels instead of being lazily created unlabelled by
--create-namespace. This makes installer-managed objects discoverable
for cleanup with simple label selectors.

Signed-off-by: Davesh Mathur <daveshm@nvidia.com>
@coderabbitai

coderabbitai Bot commented Jun 2, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 5317ee6f-3bfd-4597-9f90-92b6eceee76a

📥 Commits

Reviewing files that changed from the base of the PR and between 349ecea and 118cbe8.

📒 Files selected for processing (2)
  • installer/src/nv_config_manager_installer/deployer.py
  • installer/tests/test_deployer.py
🚧 Files skipped from review as they are similar to previous changes (1)
  • installer/src/nv_config_manager_installer/deployer.py

📝 Walkthrough

Walkthrough

This PR adds installer provenance metadata (labels and annotations) to Kubernetes resources created by the installer. It extends the K8sClient to stamp all directly-created resources with managed-by, part-of, and instance labels plus an installer-version annotation, and wires namespace pre-creation and Helm label injection into the operator CRD installation flow for Envoy Gateway, cert-manager, CNPG, and prometheus-operator.

Changes

Installer Provenance Metadata

Layer / File(s) Summary
K8s Provenance Metadata Foundation
installer/src/nv_config_manager_installer/k8s.py
Introduces provenance label/annotation constants (LABEL_MANAGED_BY, LABEL_PART_OF, LABEL_INSTANCE, ANNOTATION_INSTALLER_VERSION) and exports nv_config_manager_helm_common_labels(). Extends K8sClient.init to accept release_name and installer_version parameters, adds _object_meta() helper to build V1ObjectMeta stamped with provenance labels and installer-version annotation.
Apply Metadata Stamping to Resource Creation
installer/src/nv_config_manager_installer/k8s.py
Updates create_namespace, apply_secret, apply_docker_registry_secret, apply_file_secret, ensure_pvc, and create_loader_pod to use _object_meta() instead of bare V1ObjectMeta, ensuring all directly-created resources carry provenance metadata.
K8s Metadata Unit Tests
installer/tests/test_k8s_metadata.py
Comprehensive pytest suite with test helpers (_make_client, _assert_installer_metadata) validating metadata stamping across all resource creation methods, including secret 409 fallback behavior, installer-version annotation override, and Helm common labels generation with conditional instance label and managed-by exclusion.
Deployer K8sClient Binding and Label Helpers
installer/src/nv_config_manager_installer/deployer.py
Updates K8sClient initialization in _check_prerequisites to bind release_name. Adds _helm_common_labels_args() to convert label keys into escaped Helm --set-string arguments, and _ensure_operator_namespace() to pre-create namespaces with installer provenance labels via K8sClient.
Operator CRD Installation Wiring
installer/src/nv_config_manager_installer/deployer.py
In _install_crds, integrates namespace pre-creation and installer label/annotation injection for Envoy Gateway (commonLabels), cert-manager (global.commonLabels), CNPG (podLabels fallback), and prometheus-operator CRDs (crds.annotations), each following the chart's specific label injection mechanism.
Deployer Integration Tests
installer/tests/test_deployer.py
Updates existing _install_crds tests to explicitly bind K8sClient. Adds TestInstallCrdsProvenance test class with _run_install_crds() helper verifying namespace pre-creation and Helm label argument generation (commonLabels, global.commonLabels, podLabels, CRD annotations) for all operators.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 Hop, hop! The installer now leaves its trace,
With labels and annotations in every place,
From namespaces to pods, from secrets to crds,
Provenance metadata—the installer's own words! 🏷️

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 30.43% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main change: adding provenance labels to installer-managed Kubernetes resources, which is the primary objective across all file modifications.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch port/installer-provenance-labels

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
installer/src/nv_config_manager_installer/deployer.py (1)

1621-1651: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Stamp the connected-install cert-manager CRDs too.

global.commonLabels only covers Helm-rendered resources. In the connected-install path, the kubectl apply of cert-manager.crds.yaml still creates cluster-scoped CRDs without installer provenance, so those resources won't be discoverable for cleanup/audit the way the rest of this PR intends.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@installer/src/nv_config_manager_installer/deployer.py` around lines 1621 -
1651, After applying the upstream cert-manager.crds.yaml with _run_logged, stamp
those created cluster-scoped CRDs with the same installer labels so they’re
discoverable; specifically, after the existing _run_logged call that applies the
URL, run a second _run_logged invocation that selects the cert-manager CRDs
(e.g. via kubectl get crd -o name with a pattern for cert-manager CRDs) and
adds/overwrites the labels from cert_manager_label_args using kubectl label
--overwrite, using the same step and self.callback variables so the CRDs receive
the global/common installer labels used elsewhere (reference cert_manager_chart,
cert_manager_args, cert_manager_label_args, _run_logged, step, self.callback).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@installer/src/nv_config_manager_installer/deployer.py`:
- Around line 1621-1651: After applying the upstream cert-manager.crds.yaml with
_run_logged, stamp those created cluster-scoped CRDs with the same installer
labels so they’re discoverable; specifically, after the existing _run_logged
call that applies the URL, run a second _run_logged invocation that selects the
cert-manager CRDs (e.g. via kubectl get crd -o name with a pattern for
cert-manager CRDs) and adds/overwrites the labels from cert_manager_label_args
using kubectl label --overwrite, using the same step and self.callback variables
so the CRDs receive the global/common installer labels used elsewhere (reference
cert_manager_chart, cert_manager_args, cert_manager_label_args, _run_logged,
step, self.callback).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 3d8f7c3b-7f6c-49ee-a603-acecf14f7615

📥 Commits

Reviewing files that changed from the base of the PR and between 322a2e5 and 349ecea.

📒 Files selected for processing (4)
  • installer/src/nv_config_manager_installer/deployer.py
  • installer/src/nv_config_manager_installer/k8s.py
  • installer/tests/test_deployer.py
  • installer/tests/test_k8s_metadata.py

gateway-helm has no chart-wide commonLabels value, so the --set-string
commonLabels.* args were silently ignored and never landed on any envoy
resource. Envoy provenance already comes from the pre-created
envoy-gateway-system namespace label, which is what cleanup selectors
key off of, so drop the misleading arg and document why.

Signed-off-by: Davesh Mathur <daveshm@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant