Change:
When performing a server-side apply PATCH request, if there are conflicts in what's being applied with differing field owners, kubernetes responds with a 409 conflict error with an array of causes in the error detail, enumerating the conflicting fields that were discovered. In some cases, we see that the fields returned in this 409 error response are incorrect, containing both duplicate fields, and entirely missing other conflicts. The http 409 error response when receiving a conflict while using server-side apply should contain all of the correct fields (and also ideally no duplicates). Save this file as <details</detailsSave this file as <details</detailsNow apply the first yaml with server-side apply: Apply the second yaml with server-side apply, using a different field manager: If we get the applied daemonset at this point (), everything appears to be applied correctly with expected behavior and expected field owners Now try to re-apply with the original command/field manager, forcing a conflict error to be returned (increased verbosity to see returned http body): When re-applying this original yaml (without force-conflicts), we expect to observe conflicts on all of the fields that were changed by and now owned by the field manager. These should be: However, this is the response we get when trying to apply using the increased verbosity command: Note that the conflicts returned by the 409 error have duplicate fields, and completely omit at least 3 of the fields we are actually conflicting with. If we re-apply the original with , then the correct data is applied, and the correct field managers are set, however if we do not want to force conflicts, the conflicting fields returned in the 409 error returned from the API server are incorrect. <details</details<detailsaws eks </details<details</details<detailsTested on fresh/new EKS kubernetes cluster created with eksctl with defaults </details<details</details<details</details
/sig api-machinery
this should be fixed with
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The upstream PR that fixes this issue in kubernetes-sigs/structured-merge-diff needs to be released and pulled into kubernetes/kubernetes release branches before this issue is resolved.
/assign /triage accepted
/assign Would you want to do the dependency bump too? Thank you.
Yes, i am working on getting a new tag released for updating the dependency.
I mean, we've been able to release without the tag a few times, I still don't see what the problem is?
Actually, maybe I'm wrong ... in that case, let me add a tag

Discussion:
go kl.WatchEtcd(watchChannel, updateChannel) kl.getKubeletStateFromEtcd(key, updateChannel) <del> glog.Infof("Setting up a watch for configuration changes in etcd for %s", key) </del> <ins> glog.V(1).Infof("Setting up a watch for configuration changes in etcd for %s", key) </ins> kl.EtcdClient.Watch(key, 0, true, watchChannel, done) } }

continue } } else { <del> glog.Infof("%#v exists as %v", element.Name, actualName) </del> <ins> glog.V(1).Infof("%#v exists as %v", element.Name, actualName) </ins> } desired[actualName] = true }