ZEP-0017: Chart Namespace Overrides #18
Conversation
Racer159
commented
Feb 4, 2025
Racer159
commented
- One-line PR description: Add chart namespace overrides for Zarf packages to be deployed to the same cluster multiple times.
- Issue link: Chart Namespace Overrides #17
- Other comments:
Signed-off-by: Wayne Starr <[email protected]>
|
Leaving as a draft for initial feedback before filling additional sections. |
|
|
||
| ### Non-Goals | ||
|
|
||
| - Move away from the declarative nature of Zarf packages |
There was a problem hiding this comment.
Seems like a non goal here is to allow dynamic configuration of namespaces? If so, it would be worth discussing in the motivation why we'd want this feature for charts and not manifests. Given that manifests and charts can have the same name, if we decide to add dynamically configured namespaces for manifests in the future it'd be a breaking change.
|
|
||
| **As** Jacquline **I want** to be able to set namespace overrides **so that** I can install the same package with different configurations in different namespaces. | ||
|
|
||
| ##### Option 1 (Flatter Namespaces) |
There was a problem hiding this comment.
I like option 1 the best, I feel namespaces should be a first class citizen
There was a problem hiding this comment.
Why do we want to treat namespace specially from any other variable?
There was a problem hiding this comment.
Zarf variables are templated into manifests, values-files, and helm-charts. For example, if you had the variable ###ZARF_VAR_MY_IMAGE_TAG### in your values file and the value was set to v0.0.1, when Zarf deploys that manifest it will change the value to v0.0.1. My worry is if we also make variables a way to define namespaces based on the name of the variable, it will feel magical.
Racer159
force-pushed
the
0017-chart-namespace-overrides
branch
from
c0a9bc6 to
dd70769
Compare
Signed-off-by: Wayne Starr <[email protected]>
Racer159
force-pushed
the
0017-chart-namespace-overrides
branch
from
dd70769 to
7c37ae3
Compare
Signed-off-by: Wayne Starr <[email protected]>
|
Option 5 could also be adapted to the |
|
|
||
| **As** Jacquline **I want** to be able to set namespace overrides **so that** I can install the same package with different configurations in different namespaces. | ||
|
|
||
| ##### Option 1 (Flatter Namespaces) |
There was a problem hiding this comment.
I generally like option 1 the best, but wonder if "configurable-namespaces" should be a toggle in the package at create time? With some packages there's absolutely a desire/need to make the namespace flexible but others might struggle a lot with namespace flexibility (thinking of uds-core for example). Having the package author explicitly allow or not allow configuring namespaces might be also align with keeping the declarative nature of zarf packages even more.
Tangentially related - if templates within a zarf package/helm chart needed to access the namespace (outside of the normal EDIT: Just read below and connected dots - metadata.namespace usage) would this override be available as a zarf var or other value?.Release.Namespace could be used anywhere so this is a non-issue.
There was a problem hiding this comment.
A feature like .metadata.configurable-namespaces that defaults to true would make sense to solve that. For my understanding could you give a situation where allowing a user to configure their namespace might break a package?
There was a problem hiding this comment.
UDS Core is probably the best example I can provide. When you have multiple helm charts in a single zarf package (in this case 10+) and each needs to be aware of the namespace that the other lives in so that things like networkpolicies are properly created (or even if there were svc -> svc connections across namespaces), making sure that all works would be pretty messy since .Release.Namespace is only available within the context of the single chart. Chart A couldn't auto-detect the namespace that Chart B is deployed in, so you'd have to add another mechanism to pass chart names for "siblings" around. I think it could over-complicate a package in a way that the package maintainer doesn't want to support 😄.
There was a problem hiding this comment.
Makes perfect sense, thanks for the explanation!
There was a problem hiding this comment.
In general I'm fine with option 1, but I gotta ask: what if a helm chart or other artifact wants to deploy into more than a single namespace? Will we warn about using --namespace in that case or at least discourage in the docs or maybe that's not even possible today?
|
|
||
| **As** Jacquline **I want** to be able to set namespace overrides **so that** I can install the same package with different configurations in different namespaces. | ||
|
|
||
| ##### Option 1 (Flatter Namespaces) |
There was a problem hiding this comment.
In general I'm fine with option 1, but I gotta ask: what if a helm chart or other artifact wants to deploy into more than a single namespace? Will we warn about using --namespace in that case or at least discourage in the docs or maybe that's not even possible today?
