WIP - Stop serving deprecated extensions/v1beta1 resources by default #58819
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: liggitt Assign the PR to them by writing No associated issue. Update pull-request body to add a reference to an issue, or get approval with The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
From the 1.7 release notes: NetworkPolicy has been moved from extensions/v1beta1 to the new (kubernetes#39164, @danwinship) networking.k8s.io/v1 API group. From the 1.8 release notes: The Deployment, DaemonSet, and ReplicaSet kinds in the extensions/v1beta1 group version are now deprecated, as are the Deployment, StatefulSet, and ControllerRevision kinds in apps/v1beta1. As they will not be removed until after a GA version becomes available, you may continue to use these kinds in existing code. However, all new code should be developed against the apps/v1beta2 group version This PR disables these extensions/v1beta1 resources from being served by default in 1.10, though they can be re-enabled via --runtime-config. Objects already stored in etcd in extensions/v1beta1 format can still be read
192f9c0 to
f977cae
Compare
|
@liggitt: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
I'm worried this might break some stuff. We need to ensure these versions are not used before we disable them. Currently they are used for storage conversion and that has to be fixed, see my #43214 (comment) |
|
/hold |
This should just be disabling serving them, not disabling them in storage (the etcd storage version integration test will verify that). That said, it looks like there might be other things entangled here. Moving internal versions to the apps group might be a better first step. Also opened #58854 to start persisting in etcd in apps/v1 |
|
@liggitt PR needs rebase |
|
I have already done this by #58863. |
Not quite, this defaults to not serving these resources from extensions/v1beta1 |
|
Currently no support for disable resources under a version |
|
According @deads2k , only can support enable/disable group/version. |
Enabling and disabling particular resources inside of a GroupVersion leads to weird results. Imagine batch with cronjobs and not jobs. Or rbac without roles, but everything else. The remaining pieces don't function properly. In general, it is an anti-feature. It does not belong in the generic apiserver. I'm not convinced that we must support selective disablement of resources at all. The resource in question are still accessible via the API in other locations, so this is preventing the concepts from being used. What is the concrete benefit to doing this? The new versions exist and eventually when the entire extensions group is empty we can have a "disable the entire version by default". Removing some resources a little early (maybe) is of dubious value and adds significant complexity. @liggitt If you really feel a need to bring back the feature, I'm sure you'll keep it contained to the kube-apiserver. But I really doubt that it adds enough value to be worth the effort. |
xref #43214
From the 1.7 release notes:
From the 1.8 release notes:
This PR disables these extensions/v1beta1 resources from being served by default in 1.10, though they can be re-enabled via --runtime-config.
Objects already stored in etcd in extensions/v1beta1 format can still be read