You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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!
The text was updated successfully, but these errors were encountered:
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.)
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
Thanks!
The text was updated successfully, but these errors were encountered: