Don't fail when OpenStack config contains unknown directives #109709
Conversation
|
Please note that we're already in Test Freeze for the |
k8s-ci-robot
added
release-note
|
@mdbooth: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
k8s-ci-robot
added
needs-triage
k8s-ci-robot
added
sig/cloud-provider
CSI migration is GA in Kubernetes 1.24, all 1.24 nodes should not need in-tree OpenStack cloud provider. However, according to Kubernetes version skew policy, v1.24 KCM still needs to support nodes with v1.22 kubelet and thus it still needs to have in-tree cinder volume plugin + OpenStack cloud provider to be able to attach/detach Cinder volumes to them. IMO the cloud provider should not be used for anything else that volume attach/detach to these old nodes, the rest will be done by the external CCM. We can remove the in-tree cloud provider in Kubernetes v1.26 - KCM there can see only 1.26, 1.25 and 1.24 kubelets and all of them don't have in-tree cinder volume plugin. |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/assign @andrewsykim @nckturner This does not add a new feature to the in-tree OpenStack cloud provider, it allows adding new features to CCM while sharing the same config between KCM and CCM. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims, mdbooth The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR changes the parsing of the OpenStack cloud config to be non-strict. This is in line with the behaviour of, for example:
although some other providers remain strict.
The driver for this is the cross-over period from legacy to external CCM. For reasons I admit I do not fully understand, KCM must continue for some time to use the legacy cloud provider for the in-tree volume driver even though new volumes are created exclusively using CSI.
Prior to upgrade the user's cloud config is obviously compatible with the legacy cloud provider. After upgrade we would like to allow them to add directives which enable new functionality from OpenStack CCM. This is not possible while we are continuing to also pass this config to KCM, at least not without a level of pre-parsing which presents its own maintenance issues.
This change makes KCM ignore directives it does not understand. Rather than ignoring this entirely, as seems to be normal, we emit a friendly warning which should hopefully allow the user to confidently ignore it if it does not apply.
@jsafrane I wonder if you could expand on the reasons KCM still needs in-tree volume support?
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: