Investigate alternative notion of managed resources than app.kubernetes.io/instance label

[alexec]

No description provided.

[jessesuen]

For more context. See:

• Make it possible to set release name different from argcd app name.  #1066 (comment)
• Make it possible to set release name different from argcd app name.  #1066 (comment)

Essentially this issue is for us to find an alternative way to detect what is considered a "managed" resource of an application, which wouldn't involve label injection.

The issue that we currently face with the app.kubernetes.io/instance label is that there is friction about using this label with other common tooling such as:

• helm - which started using app.kubernetes.io/instance as part of their default template generation, including using app.kubernetes.io/instance in selectors.
• kustomize - which has a commonLabels feature that also potentially injects app.kubernetes.io/instance into selectors (provided the user specifies app.kubernetes.io/instance in their commonLabels).

Since v0.11, Argo CD no longer requires that the resource association to be driven by a label. Previously we depended on a label so that we could perform efficient kubernetes queries to perform resource discovery. Now, however, our live state metadata cache enables us to efficiently discover all resources associated with an application, without the use of a label. We simply need to inject the application name somewhere in the resource object. This could be a:

• label (what we have today)
• annotation
• ownerReference (assuming cross-cluster ownerReference is valid)

In summary, our injection of app.kubernetes.io/instance seems that it may be too opinionated, causing the problems.

My ideal solution would be to inject an ownerReference to all managed resources that Argo CD deploys. However, I do not know if this is valid thing to do when the "owner" is a resource in an entirely different cluster. I posed this question to sig-api-machinery, and still waiting a response.

[alexec]

Note we might wish to use argocd.argoproj.io/instance for this as that is our convention.

[alexec]

@jessesuen did you get a response to your query in sig-api-machinery

[alexec]

Document work-around.

[yann-soubeyrand]

Hi,
Shouldn't Argo CD use the common app.kubernetes.io/managed-by label (https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)?
Edit: well, charts tend to set this label to helm so it would also conflict.