Preffer `kubectl.kubernetes.io/last-applied-configuration` over `qbec.io/last-applied`

[kvaps]

It's up to consideration.

I think it makes sense to prefer kubectl.kubernetes.io/last-applied-configuration annotation over qbec.io/last-applied and always remove the first one because of the few reasons:

• If both annotations exists, then most probably resource was applied using qbec and using kubectl afterwards. This means we need to consider the latest configuration applied via kubectl, and ignore qbec annotation.
• Better integration with ArgoCD, since it uses kubectl for applying resources, we don't need --show-pristine option anymore. Another problem of --show-pristine is the fact that it adds additional difficulties for hiding this information (see https://github.com/argoproj/argo-cd/issues/5201) I think this solution is better and more clear than proposed on https://github.com/splunk/qbec/issues/163 and PR https://github.com/splunk/qbec/issues/167.

Current behavior:

qbec.io/last-applied	kubectl.kubernetes.io/last-applied-configuration	Behavior
missing	missing	use resource body, write qbec.io/last-applied
exists	missing	use qbec.io/last-applied, write qbec.io/last-applied
missing	exists	use kubectl.kubernetes.io/last-applied-configuration, delete kubectl.kubernetes.io/last-applied-configuration, write qbec.io/last-applied
exists	exists	use qbec.io/last-applied, write qbec.io/last-applied

My idea is to change the last case behavior to:

qbec.io/last-applied	kubectl.kubernetes.io/last-applied-configuration	Behavior
exists	exists	use kubectl.kubernetes.io/last-applied-configuration, delete kubectl.kubernetes.io/last-applied-configuration, write qbec.io/last-applied

[gotwarlost]

You could make the counter argument.

If both are present, the project is likely transitioning from kubectl to qbec

I think as long as there are 2 annotations potentially in conflict, picking any one will always cause some case to fail.

I think what we need is the ability for qbec to use kubectl annotations when configured for a qbec app. That is, a flag in the qbec spec that says:

   impersonateKubectl: true

and if this is set qbec always writes a kubectl.kubernetes.io/last-applied-configuration annotation instead of the qbec one.

qbec already has the logic to read its own annotation and then kubectl's,. This is preserved as before.

For brand-new projects everything works the same except that qbec is writing the kubectl annotation and reading (as a 2 step process since the qbec version won't exist) it.

qbec should also have the logic to remove any qbec annotation that was present in the object when the project says it wants to impersonate kubectl and remove it going forward.

For a project that wants to transition to this, we need to document the migration process. This is, roughly,

• do not add the flag, apply using qbec one time such that the qbec annotation is the latest version
• add the flag and re-apply
• this will cause qbec to compute diffs based on its annotation, delete it and use the kubectl version on apply so that subsequent runs are clean

[kvaps]

I think as long as there are 2 annotations potentially in conflict, picking any one will always cause some case to fail.

That's not fully true, as the only case when both of them are existing is when kubectl is used over qbec. The purposed change should not break anything but it will consider the changes made by hand via kubectl.

I think what we need is the ability for qbec to use kubectl annotations when configured for a qbec app. That is, a flag in the qbec spec that says:

impersonateKubectl: true

and if this is set qbec always writes a kubectl.kubernetes.io/last-applied-configuration annotation instead of the qbec one.

What the reason we need qbec annotation then why not always using kubectl annotation instead?

[kvaps]

@gotwarlost do you want to generate and write kubectl.kubernetes.io/last-applied-configuration annotation by qbec, right? It would need some additional modifications in method as kubectl applies the namespace name there.