Preffer `kubectl.kubernetes.io/last-applied-configuration` over `qbec.io/last-applied`
kvaps opened this issue · 3 comments
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 argoproj/argo-cd#5201) I think this solution is better and more clear than proposed on #163 and PR #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 |
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
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?
@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.