feat(deploy): support for package namespace override flag

[brandtkeller]

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

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[netlify]

✅ Deploy Preview for zarf-docs canceled.

Name	Link
🔨 Latest commit	e771e64
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/684b14e5b0e0e0000875919d

[codecov]

Codecov Report

Attention: Patch coverage is 27.46479% with 103 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/pkg/packager/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/pkg/packager/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 ⚠️
src/cmd/crane.go	0.00%	1 Missing ⚠️
... and 1 more

Files with missing lines	Coverage Δ
src/cmd/viper.go	53.08% <ø> (ø)
src/pkg/cluster/tunnel.go	10.08% <100.00%> (ø)
src/pkg/packager/load.go	57.14% <100.00%> (ø)
src/pkg/packager/packager2.go	48.57% <100.00%> (+30.38%)	⬆️
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/pkg/packager/remove.go	0.00% <0.00%> (ø)
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.

[AustinAbro321]

A few nits on an overall simple & elegant solution

[AustinAbro321]

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

[AustinAbro321]

One small nit, otherwise lgtm

[Racer159]

😈

[brandtkeller]

@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.

[AustinAbro321]

Yeah excellent call out @Racer159. A similar concern is that other packages might have operators or actions expecting that the package deploys to a particular namespace.

IMO we should provide a metadata field that allows users to enable/disable the ability to override the package namespace . Maybe allowNamespaceOverride. I'm undecided if allowNamespaceOverride should default to false or true, but I'm leaning towards false. On one hand this feature is not dangerous in the majority of situations since it's only applicable to single namespaces. On the other hand, this is an alpha feature and if we open up in the future to allowing X namespace overrides it could get more dangerous.

[brandtkeller]

Added a check to match the current constraint for overrides not supporting InitPackages (yet).

[AustinAbro321]

What do you think of a metadata field on the Zarf package such as allowNamespaceOverride? It'd be unlikely but feasible that a user has a custom init package that could deploy to a single namespace. However, the more likely scenario that we should address is packages built with implicit knowledge of their namespace either through actions, an operator, or another mechanism. In those situations, we should give package creators a lever to turn off namespace overrides.

If we go this route we should also consider if we want the field to default to false and force package creators to opt into it. On one hand namespace overrides are not dangerous since it's only applicable to single namespace packages. On the other hand, this is an alpha feature and if we open up in the future to allowing namespace overrides in a package with multiple namespaces it could get messy.

[brandtkeller]

Valid suggestion - I appreciate consideration of having a mechanism to disable namespace overrides. I'd like to keep scope minimal as to warrant more feedback from the community.

Given this is not a security consideration (rather more UX) I am inclined to propose a default that allows namespace overrides to occur unless otherwise declared - preferably using the bool default value.

disableNamespaceOverride?

[AustinAbro321]

FWIW we did get that feedback on the original proposal, though that was in the context of multiple configurable namespaces - zarf-dev/proposals#18 (comment)

Yeah I'm fine with that. Generally we've been trying to avoid introducing fields in the schema starting with a negative (I.E. NoWait will become Wait in the next schema version). We can use boolptrs to make the default true or false. Though since we need a verb either way (I don't think just namespaceOverrides is clear enough) I don't feel too strongly on allow vs disable

[brandtkeller]

Good context and I do agree that it is a reasonable extension of scope - That thread might have concluded without getting the information ultimately included in the ZEP itself (Or I missed it when mapping requirements).

words are hard and a non-negative wasn't easily identified - but I do like to stick to the style. Given that we can unmarshall to true by default and check for nil I think boolptr here is reasonable (albeit not an option I will typically reach for).