Ability to control deploy-to namespace using a Zarf Variable

[RothAndrew]

Is your feature request related to a problem? Please describe.

I have to deploy the same zarf package more than once to the same cluster, using a different namespace each time. The number of deployments needed and namespace names are both not always known in advance.

Describe the solution you'd like

• Given I have a Zarf variable called NAMESPACE and a zarf.yaml component like:

components:
  - name: my-app
    required: true
    charts:
    - name: my-app
      localPath: ./
      namespace: "###ZARF_VAR_NAMESPACE###"
      version: 1.2.3
      valuesFiles:
      - values.yaml

• When zarf package deploy --set NAMESPACE=foo is run and followed by zarf package deploy --set NAMESPACE=bar
• Then "my-app" is deployed to the namespace "foo", followed by a 2nd instance of "my-app" being deployed to the namespace "bar".

Describe alternatives you've considered

• Using create-time variables, but that would require managing multiple built .tar.zst files which is undesirable
• Using multiple optional components, but that's (a) an ugly hack, and (b) requires both the namespace names as well as the maximum possible number of deployments to be known in advance.

[NunoSav]

I've achieved this by defining namespace only in the manifests (removed from zarf.yaml) with value set to ###ZARF_VAR_NAMESPACE### and then zarf package deploy --set NAMESPACE=xyz.

Warning: Zarf will only be able to deploy one version of such deployment, deleting any previous one using same package.

[ntwkninja]

I've achieved this by defining namespace only in the manifests (removed from zarf.yaml) with value set to ###ZARF_VAR_NAMESPACE### and then zarf package deploy --set NAMESPACE=xyz.

Warning: Zarf will only be able to deploy one version of such deployment, deleting any previous one using same package.

Do you know if there is a way to template the zarf package name? In our case, we're wanting to deploy the same package twice to a single cluster without overriding the previous.

[JoeHCQ1]

We get the same problem but worse (can't override at the UDS bundle level(?)) with the onDeploy wait commands. They're often used like this to ensure the system is totally up:

    actions:
      onDeploy:
        after:
          - description: Validate Valkey Package
            maxTotalSeconds: 300
            wait:
              cluster:
                kind: packages.uds.dev
                name: valkey
                condition: "'{.status.phase}'=Ready"
                namespace: valkey
          - description: Valkey to be Healthy
            maxTotalSeconds: 90
            wait:
              cluster:
                kind: pod
                name: app.kubernetes.io/name=valkey
                condition: Ready
                namespace: valkey

The problem is this is hardcoded now into the package, and at the bundle level I may be redeploying to a different namespace. The consequence is that I have to override both of the component namespaces (as mentioned above) and these on-deploy values. It makes this layer of encapsulation rather porous.

To speak outside of UDS terms, if you're trying to deploy a package down the road, this kind of hard-coded build-time namespace declaration is a pain. If I could just reference a Zarf var in this package config I think I could fix it (it's always ZARF_VAR_NAMESPACE). If we took a queue from Helm, this kind of value could also be baked in - a reserved name.

[mkcp]

Related zarf-dev/proposals#18