kustomize: image name/tag cannot be set from base

I have a use case for this. Let’s say we have the following GitOps setup.

• base
  • deployment.yaml
  • kustomization.yaml
• overlay
  • dev
    • configmap.yaml
    • kustomization.yaml
  • tst
    • configmap.yaml
    • kustomization.yaml
  • acc
    • configmap.yaml
    • kustomization.yaml
  • prd
    • configmap.yaml
    • kustomization.yaml

I would like my deployment to defined in the base, so we set the image in base/kustomization.yaml. This works for tst, acc and prd, but for dev we might want something different, e.g. a snapshot build of the latest commit or an image with additional debug tooling. It would be useful to override the image of base/kustomization.yaml in overlay/dev/kustomization.yaml.

@yujunz I don’t see how this limitation ensures a more deterministic build.

As soon as you are relying on base files, any modification to these base files impacts the kustomization using them, be it resources or images seems like the same to me.

Being able to specify images in base files also does not cripple flexibility for overlays, you can still modify again images in each overlay kustomization file.

From what I understand, it seems that this feature would increase even more the ability to factor kustomization code.

Would you mind detailing a bit more why this feature would impeach deterministic build and flexibility (perhaps through examples)?

ok… but is this important? its making quite a bit more work and harder to maintain.

It is possible to achieve the same effect by adding the image to each overlay. It would just be more DRY if, when we have a number of overlays share the same image, we could specify the image in base and override it only when necessary. After all, not repeating shared configuration is sort of the point of Kustomize.

I will attempt to explain our situation for some background information. In our project, we have a gitops setup with a branch for each environment. The dev overlay on the dev branch is automatically deployed with ArgoCD, as is the tst overlay on the tst branch, etc. When we finish a feature, we update all the kustomize overlays on branch dev to reflect the new version number tag. This means the production config is already written as part of the feature. When the time comes to release, we merge branch dev (with the updated overlays) into branch tst, later acc, then prd. By doing these merges we can ensure that we have the exact same image tag that is deployed to tst, also deployed to acc and prd.

That said, the loophole in this process is that someone might update a version number only in the tst overlay, and forget to do it for acc and prd. So when we merge the tst branch into acc, the acc overlay still has the old tag and no deployment is done by ArgoCD. We could avoid that scenario with an image tag specified in the base: anyone who would update the tag for one deployment has done so for tst, acc and prd at the same time. The dev overlay stays the same here because it always points to :latest.

@donbowman IMO, your use case is counter to the kustomize design. Each layer, or kustomization is self-contained. ../common shouldn’t have any knowledge of its sibling ../base (because they are organized by overlay and don’t have a solid logic relationship).

The use case from @Oduig makes more sense. However I cannot see what is preventing you from modifying the images name and tag in overlay. Image transformer should be able to override the value from base.

Any news on this, will this feature be considered for implementation?

Hello @yujunz,

OK, I see your point now. For the example to be more complete, a new deployment using the image cr.agilicus.com/group/image should be declared in the overlay and the question that would arise would be which tag will use this deployment?

Still this could be rendered deterministic by simple rules like “last one wins”, which would mean that the stage tag would be applied to this overlay declared deployment.

I think we have in mind two different use of bases.

Your example shows this type of dependency:

• O -> B1
• O -> B2

My intent (and perhaps what is needed by @donbowman) is more to obtain a DRY approach for this type of dependency:

• O1 -> B
• O2 -> B

Both types of use can occur and supporting things like “last one wins” would still make the result deterministic. However I agree that implementing this is perhaps not easy.

This is by design. Similar to namePrefix or commonAnnotations, they only set or modify the resources manged by the current kustomization.