Skip to content

feat(deploy): support for package namespace override flag #3889

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

brandtkeller
Copy link
Member

@brandtkeller brandtkeller commented Jun 3, 2025

Description

This pull request adds support for a --namespace flag in the deploy operation - allowing users with a single-namespace package to deploy the package multiple times to multiple isolated namespaces. This is the implementation for proposal ZEP-0017.

Constraints

  • This does not support package namespace overrides for ZarfInitConfig packages.

Design Choices

  • Use of ZarfPackage methods for validating a package has only declared a single namespace & updating all package components to the target namespace
  • Add NamespaceOverride as a new field under DeployedPackage
    • Use of functional options for setting namespace - while it is exposed - helps provide a mechanism where the signature of existing cluster methods do not need to be modified.
    • Exposing the NamespaceOverride field with json tags allows us to store it in the package state secret. Any call to cluster.GetDeployedZarfPackages will have the information innately.
    • Ensures secret delineation should not conflict by not using package name solely for secret identification.
    • formats overriden state secret with zarf-package-my-package-override-namespacename such that the collisions should only occur in a very specific edgecase.
  • Logic/Testing for config file override is included
  • Updates DeployedPackage and remaining "k8s" types to state package.
  • Backwards compatible with older versions of Zarf - allowing for package list/inspect operations without panic.

Related Issue

Fixes #2407

Checklist before merging

@brandtkeller brandtkeller self-assigned this Jun 3, 2025
Copy link

netlify bot commented Jun 3, 2025

Deploy Preview for zarf-docs canceled.

Name Link
🔨 Latest commit 36d60f1
🔍 Latest deploy log https://app.netlify.com/projects/zarf-docs/deploys/684893a1e2105b0009675390

Copy link

codecov bot commented Jun 3, 2025

Codecov Report

Attention: Patch coverage is 19.25926% with 109 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/internal/packager2/deploy.go 0.00% 25 Missing ⚠️
src/api/v1alpha1/package.go 0.00% 19 Missing ⚠️
src/cmd/package.go 33.33% 16 Missing ⚠️
src/pkg/cluster/zarf.go 48.14% 14 Missing ⚠️
src/pkg/message/connect.go 0.00% 10 Missing ⚠️
src/pkg/state/state.go 0.00% 10 Missing ⚠️
src/internal/packager2/packager2.go 0.00% 6 Missing ⚠️
src/internal/packager2/remove.go 0.00% 4 Missing ⚠️
src/internal/packager/helm/post-render.go 0.00% 2 Missing ⚠️
src/cmd/connect.go 0.00% 1 Missing ⚠️
... and 2 more
Files with missing lines Coverage Δ
src/cmd/viper.go 53.08% <ø> (ø)
src/internal/packager2/load.go 57.55% <100.00%> (ø)
src/pkg/cluster/tunnel.go 10.08% <100.00%> (ø)
src/cmd/connect.go 32.63% <0.00%> (ø)
src/cmd/crane.go 29.82% <0.00%> (ø)
src/internal/packager/helm/chart.go 1.29% <0.00%> (ø)
src/internal/packager/helm/post-render.go 0.00% <0.00%> (ø)
src/internal/packager2/remove.go 0.00% <0.00%> (ø)
src/internal/packager2/packager2.go 14.28% <0.00%> (-3.90%) ⬇️
src/pkg/message/connect.go 0.00% <0.00%> (ø)
... and 5 more
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@brandtkeller brandtkeller marked this pull request as ready for review June 3, 2025 22:05
@brandtkeller brandtkeller requested review from a team as code owners June 3, 2025 22:05
Copy link
Contributor

@AustinAbro321 AustinAbro321 left a comment

Choose a reason for hiding this comment

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

A few nits on an overall simple & elegant solution

@brandtkeller brandtkeller marked this pull request as draft June 4, 2025 18:36
@brandtkeller brandtkeller marked this pull request as ready for review June 6, 2025 21:15
Copy link
Contributor

@AustinAbro321 AustinAbro321 left a comment

Choose a reason for hiding this comment

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

I like the change in direction, a few suggestions + calls for unit tests


CmdPackageMirrorFlagComponents = "Comma-separated list of components to mirror. This list will be respected regardless of a component's 'required' or 'default' status. Globbing component names with '*' and deselecting components with a leading '-' are also supported."
CmdPackageMirrorFlagNoChecksum = "Turns off the addition of a checksum to image tags (as would be used by the Zarf Agent) while mirroring images."

CmdPackageInspectFlagSbomOut = "Specify an output directory for the SBOMs from the inspected Zarf package"
CmdPackageInspectFlagListImages = "List images in the package (prints to stdout)"
CmdPackageInspectFlagNamespace = "[Alpha] Override the namespace for package inspection. Requires the package to have been deployed using the namespace override."
Copy link
Contributor

Choose a reason for hiding this comment

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

Requires feels like the wrong verb here. Maybe something like Applicable only to in-cluster packages deployed to a dynamic namespace. Ditto for remove

Copy link
Member Author

Choose a reason for hiding this comment

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

That is fair! modified to potentially meet this intent.

Comment on lines 293 to 299
if opts.NamespaceOverride != "" {
nsCount := pkgLayout.Pkg.GetUniqueNamespaceCount()
if nsCount > 1 {
return nil, fmt.Errorf("package contains %d namespaces, cannot override namespace to %s", nsCount, opts.NamespaceOverride)
}
pkgLayout.Pkg.SetPackageNamespace(opts.NamespaceOverride)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I get why we validate and set the package namespace early here, but we should also validate and set the package namespace at the CLI level. Currently, Deploy accepts the NamespaceOverride opt, but if someone is calling the function purely at the SDK level, then it will only have an impact on the secret, not on the namespace the package is deployed to. To avoid duplication, one option would be to make a common function in packager2 both deploy and the cli can call.

Copy link
Member Author

Choose a reason for hiding this comment

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

Great points - I tested a few different strategies for locality of the namespace override identifiers and ultimately landed on your thoughts as well. Isolating the logic in a common function and then duplicating across CLI/SDK to meet parity while primarily isolating the core logic to DeployOptions and Deploy().

Copy link
Contributor

@AustinAbro321 AustinAbro321 left a comment

Choose a reason for hiding this comment

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

One small nit, otherwise lgtm

@@ -24,6 +24,7 @@ zarf package remove { PACKAGE_SOURCE | PACKAGE_NAME } --confirm [flags]
--components string Comma-separated list of components to remove. This list will be respected regardless of a component's 'required' or 'default' status. Globbing component names with '*' and deselecting components with a leading '-' are also supported.
--confirm REQUIRED. Confirm the removal action to prevent accidental deletions
-h, --help help for remove
-n, --namespace string [Alpha] Override the namespace for package removal. Applicable only to packages deployed using the namespace override flag.
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're adding the -n shorthand we should add it to the other commands. Also we should just say the "namespace flag" instead of "namespace override flag" imo.

@Racer159
Copy link
Contributor

😈
image
image
image

@brandtkeller
Copy link
Member Author

@Racer159 you raised a good point that a constraint behind this is that it does not support init-packages to-date. We'd need to rewire all of the hardcoded assumptions around the zarf namespace, state, etc.

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.

Ability to control deploy-to namespace using a Zarf Variable
3 participants