Open chrischdi opened 2 years ago
Sounds good to me, I'm generally +1 to follow the best practice to define the list type.
I personally wouldn't consider this a breaking change. I think depending on how we set it, it could make the merge behavior of kubectl more precise, but I think that's rather a bugfix.
+1 this goes in the direction of @JoelSpeed suggestions about API conventions /milestone v1.2
+1
Today, because lists are atomic by default, clients will have to observe the entire list, make their updates, and patch the entire list. By adding these annotations, we won't break the existing usage as they will still allow sending the entire list.
Do we know if any of our controllers are already attempting to use server side apply? The only break I could think of is if any controllers are already using SSA, they will go from owning the list to owning all the items in the list. Others would have to use force to override that. If there is already a controller doing this, I would expect this to have already been a problem though.
This assumes of course that the manager name differs, which I know we haven't resolved yet.
In all though, it should allow the controllers to simplify their logic once they do make the move to SSA
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/triage accepted /lifecycle frozen
/remove-kind bug /kind api-change
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
/triage accepted
/priority important-longterm
What steps did you take and what happened:
While implementing #6462 I stumbled across the warning that we do not define
list-type
for slices in our v1beta1 structs:This should be the same also for occurencies in
v1alpha3
andv1alpha4
.What did you expect to happen:
API rule violation warning does not occur
Anything else you would like to add:
Adding the list-type helps to improve support for server-side apply and allows to define the merge-strategy for server-side apply.
Especially when continuing at #6320 results in making use of server-side apply (as currently proposed) works out adding the list-type to the defintions help improving support here.
Setting the list-type may be considered as a breaking change and may require a new api version.
Environment:
kubectl version
):/etc/os-release
):/kind bug /area api