Flatcar OSP breaks against Flatcar 3602.2.0

[jstremick]

Same issue as kubermatic/kubermatic#12690

One file resource needs to be removed from the Flatcar OSP as it now conflicts with the unit defined here because they are both trying to manage the same file path.

This change in behavior can be traced back to coreos/ignition#1456

[ahmedwaleedmalik]

Thanks for creating the issue and the helpful details. I could only reproduce this issue on AWS since it has some default ignition config, mainly for EKS, that conflicts with the OSPs. I couldn't reproduce this on the stock 3602.2.0 flatcar image on other cloud providers. Anyways, this duplication needs to be removed regardless.

[jstremick]

Gotcha, we are indeed hitting this on AWS.

Will this PR be undone in favor of this fix?

[ahmedwaleedmalik]

Yes, that's correct, kubermatic/machine-controller#1711 will be reverted in favor of #314.

Thanks a lot for helping with this :D

[ewassef]

I tried manually updating the version of the osp to quay.io/kubermatic/operating-system-manager:v1.3.3 but have not been able to get the machines to come up with kubelet yet. When can we anticipate this will be fixed with a kkp release? Flatcar is currently DOA

[ahmedwaleedmalik]

@ewassef we had patch releases for KKP yesterday that include an updated OSM with the fix.

https://github.com/kubermatic/kubermatic/releases