tanka
tanka copied to clipboard
"server" apply strategy fails to apply with conflicts when Flux in use
We have Flux (v2) managing our deployments.
We wanted to try server-side applies which are supported by tanka. Since my environment here is an inline environment I added tanka.environment.withApplyStrategy('server') to its tanka.environment.new() call. Then running tk apply failed like this:
Please type 'yes' to confirm: yes
error: Apply failed with 1 conflict: conflict with "kustomize-controller": .spec
Please review the fields above--they currently have other managers. Here
are the ways you can resolve this warning:
* If you intend to manage all of these fields, please re-run the apply
command with the `--force-conflicts` flag.
* If you do not intend to manage all of the fields, please edit your
manifest to remove references to the fields that should keep their
current managers.
* You may co-own fields by updating your manifest to match the existing
value; in this case, you'll become the manager if the other manager(s)
stop managing the field (remove it from their configuration).
See https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts
Error: exit status 1
Same would probably happen in the spec.json instead.
I didn't try but tk apply --force would probably have worked. Maybe an extra field on the spec to set force would do it? Not sure if that would mess with Flux and stop it reconciling. The expectation would be these updates are overwritten by Flux unless you have suspended the Kustomization.
https://github.com/grafana/tanka/blob/008c651ae883b00def940ff17dd36df5e6c0289f/pkg/kubernetes/client/apply.go#L26
--force is mapped inside of tanka to mean --force-conflicts when used along with the server-side apply strategy 👍
So basically the outcome of that issue should be an additional to the environment spec that controls the force flag?
Not sure. Could server imply using --force all the time and then you don't need to set two flags to use server in this configuration (with flux)?