Render application label through kustomize instead of replacing after

[KarstenSiemer]

Hello,

by default when argocd is used with kustomize, it sets the instance label as the application name.
The problem here is that is does this after the kustomization was rendered.
e.g

argo-cd/reposerver/repository/repository.go

Line 332 in 16e645b

for _, target := range targets {

kube.SetAppInstanceLabel(target, q.AppLabelKey, q.AppLabelValue)

This potentially causing errors when users are utilizing variables inside kustomize where they are doing operations on that label or with the value of that label.
This could be avoided by rendering the application label with kustomize in the first place.
All operations would stay valid

at the time this can be avoided by using the commonLabel feature introduced here:
b645589

Yet, i think, i would be more favorable to do it right in the first place

[alexec]

Hi - can you please provide repro steps?

[KarstenSiemer]

1. Have a base with a commonLabel for instance label e.g. app.kubernetes.io/instance=test
2. Take the value of the instance label and save it to a var inside kustomization:

vars:
- name: INSTANCE
  objref:
    apiVersion: v1
    kind: Service
    name: taskmanager
  fieldref:
    fieldpath: metadata.labels[app.kubernetes.io/instance]

3. Use that variable in a crd and configure the field for it, for example in a selector inside a servicemonitor from prometheus-operator. Also configure the field to have commonLabels created.

selector:
    app.kubernetes.io/test: $(INSTANCE)
    app.kubernetes.io/instance: $(INSTANCE)

4. When rendered via kustomize build, inside that selector there will be the value 'test'
5. When now consumed by argocd, the app.kubernetes.io/test label does not have the variable of $(INSTANCE) in it but is now test.
6. Argocd replaces the value 'test' of the instance label with the application name.
7. The value of app.kubernetes.io/test does not have the actual value of the instance label any more.
8. Apparently the instance label inside the selector will also not be replaced by argocd. This from a deployment that was build like that:

Labels from a service:

labels:
    app.kubernetes.io/component: jobmanager
    app.kubernetes.io/instance: stage-test

Selector from a servicemonitor:

selector:
    app.kubernetes.io/component: jobmanager
    app.kubernetes.io/test: test-stage
    app.kubernetes.io/instance: test-stage

So the instance label inside the kustomization was set to test-stage, but the application name was chosen to be stage-test.

Actually the structure used here is weird on many levels, but one of our devs actually tried to build like this and was confused as to why his manifest isn't working inside kubernetes.

Trying to make this less confusing, i'd say that the instance label argocd is replacing should be injected into the kustomization as a commonLabel instead of replacing it after kustomize was rendered. Or maybe to do both, what if a crd path is not configured for create in respect to commonLabels?

[alexec]

Thank you Karl.

Argo CD uses a label, by default app.kubernetes.io/instance, to identify what resources comprise the app. Therefore if the tool uses that label as well, a conflict occurs. Changing the code to not apply this if the tool has applied it already would mean that Argo CD could not reconcile the app - it would not be able to know which resources comprise it.

You can change the label used from it's default value by following these instructions:

https://argoproj.github.io/argo-cd/faq/#why-is-my-app-out-of-sync-even-after-syncing

Alex

See also #1482.