Remove use of alpha initializers#72972
Conversation
|
added to the sig-api-machinery meeting agenda on 1/16 for discussion |
e731e22 to
c657236
Compare
|
Did we want to keep the field so that we don't break downstream and remove it in a future release? |
Current state:
We can consider keeping the field in metadata and unconditionally clearing it server-side, but I don't see what would make it safer to remove in a future release than it is now I'd prefer to remove it from the schema to avoid generating misleading clients |
c657236 to
18018ed
Compare
|
@kubernetes/sig-cloud-provider-pr-reviews |
|
@liggitt is this targeting v1.14? |
|
yes |
|
@liggitt I understand, but IncludeUninitialized also had the effect to be able to list resources that are pending finalization (e.g. those that have a non-nil DeletedTimestamp, but a non-empty list of finalizers). How can we list resources that are in this case ? (my use case is within a custom controller, which uses a watch and respond to this condition) |
|
(an example of that, is for writing custom finalizers: https://github.com/hossainemruz/k8s-initializer-finalizer-practice/blob/master/pkg/controller/deploymentcontroller.go#L62) |
Objects pending finalization are included regardless of the |
Revised the config.yaml file for resource changes happened in 1.14. This also adds the latest swagger.json from release-1.14 branch. Resource (type) changes: - `CSIDriver` and `CSINode` added to `storage.v1beta1` group; - `VolumeAttachement` graduated from `storage.v1beta1` to `v1`; - `InitializerConfiguration` from `admissionregistration.v1alpha1` was dropped (kubernetes/kubernetes#72972); - `PriorityClass` graduated from `scheduling.v1beta1` to `scheduling.v1`; - new resource `auditregistraion.v1alpha1.AuditSink` got added; - new resource `coordination.v1.Lease` got added; - new resource `node.v1beta1.RuntimeClass` got added;
Due to kubernetes/kubernetes#72972 the alpha `Initializers` feature will be entirely removed with Kubernetes 1.14. We are currently relying on it as the cloud-controller-manager uses it to label persistent volumes before they become visible in the API. This functionality is also removed (see kubernetes/kubernetes#73102) with 1.14. As a consequence, in order to use PV labelling until the community has migrated all CCMs to use `MutatingWebhookConfiguration`s for that, the only way is to enable the (already deprecated) `PersistentVolumeLabel` admission controller in the kube-apiserver. That means that the kube-apiserver needs to talk to the cloud provider to figure out the region/zone of the PV (and later add them as label). --> We have to provide the cloud credentials + config to the API server in this case. Shoot clusters with Kubernetes version < 1.14 still have an enabled initializer feature.
Finalizers are removed in 1.14 kubernetes/kubernetes#72972
Finalizers are removed in 1.14 kubernetes/kubernetes#72972
Initializers are removed in 1.14 kubernetes/kubernetes#72972
* Remove initializers feature gate Initializers are removed in 1.14 kubernetes/kubernetes#72972 * Update feature-gates.md
Initializers are removed in 1.14 [1] [1]: kubernetes/kubernetes#72972
Initializers are removed in 1.14 [1] [1]: kubernetes/kubernetes#72972
Initializers are removed in 1.14 [1] [1]: kubernetes/kubernetes#72972
Initializers are removed in 1.14 [1] [1]: kubernetes/kubernetes#72972
Initializers are removed in 1.14 [1] [1]: kubernetes/kubernetes#72972
Initializers are removed in 1.14 [1] [1]: kubernetes/kubernetes#72972
Initializers are removed in 1.14 [1] [1]: kubernetes/kubernetes#72972
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
IncludeUninitializedfield from*OptionsmarkInitialized()method to no-op). This controller will either need to work off of a different attribute (like an annotation), or become an admission webhook.Which issue(s) this PR fixes:
Fixes #67113
Special notes for your reviewer:
There are no plans to graduate the initializers feature, so removing it sooner rather than later sends a clearer signal to the community that new features should not be built anticipating its promotion.
Does this PR introduce a user-facing change?:
/sig api-machinery
/cc @lavalamp @deads2k @smarterclayton @caesarxuchao