Skip to content
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

Image policy marker format with namespace substitution #860

Open
kvandenhoute opened this issue Mar 5, 2025 · 0 comments
Open

Image policy marker format with namespace substitution #860

kvandenhoute opened this issue Mar 5, 2025 · 0 comments

Comments

@kvandenhoute
Copy link

kvandenhoute commented Mar 5, 2025

When setting an image policy marker format, the namespace has to be included. In our way of deploying, this seems to be a hard feat.

We deploy using application repositories. They contain the resources for an application and the specific configuration for a cluster. They use a Kustomization substitute ${NAMESPACE} for the namespace and the Kustomization has targetNamespace for that namespace.

For example:
base/application_component_1/helmrelease.yaml
clusters/cluster_A/secrets/...
clusters/cluster_A/flux/imagepolicy.yaml
clusters/cluster_A/flux/imageautomation.yaml
clusters/cluster_A/flux/imagerepository.yaml
clusters/cluster_A/kustomization.yaml (includes all of the above, and is the path of the Flux Kustomization which has the substitutes)

Now if we want to use the image automation controller, in our ./base/helmrelease we have to add the kyaml setter (if at some point we want the version to be specific per cluster, we will move this the ./cluster instead of ./base.)

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: app
  namespace: ${NAMESPACE}
spec:
...
  values:
    image:
      tag: cicd-18 # {"$imagepolicy": "${NAMESPACE}:app:tag"}

The thing we are struggling with here is that ${NAMESPACE} can not be used as it will not be substituted when using kyaml, so we have to use the hardcoded namespace name. However, this is the thing we try to abstract from our repository, as the repository will be re-used for multiple namespaces which will be 'orchestrated' from another gitrepo.

We could break with our practice, or we could move the imageautomation to where the Kustomization is defined, but we would like to keep it here.

Do you have any suggestions how to handle this, or would it need a change to the image automation controller?

I had some ideas, but they involve changes, which is why I first ask whether this can be done as-is.

Ideas

  • Having the option to leave the namespace blank / generic ('ALL or something alike') / removing the namespace accompanied with a flag on the policy to allow the blank/generic/no namespace
  • Having the option to use a constant namespace name on the policy, so that instead of policy.getNamespace() , policy.getNamespaceOverride() is used, which can be '${NAMESPACE}' (literal) (or some other variable)

Thanks!

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

No branches or pull requests

1 participant