Drop support for OpenStack in-tree plugin

[mandre]

The in-tree openstack provider is gone from kube 1.26.

[JoelSpeed]

This makes sense for the issue we are trying to solve, but I wonder where else this might be used, have we done a code search to work out where this is used to check this change isn't going to break other consumers?

[mandre]

This makes sense for the issue we are trying to solve, but I wonder where else this might be used, have we done a code search to work out where this is used to check this change isn't going to break other consumers?

Yes, it seems to me this code is only used in KCMO, where I want to use it.

https://github.com/search?q=org%3Aopenshift+GetPlatformName&type=code

[mandre]

Hold on, I notice we're also making a call to GetPlatformName() in ObserveCloudProviderNames(), but I think it's fine. Would appreciate a second pair of eyes though.

Perhaps I should also remove reference to openstack being a valid cloud provider.

[openshift-ci]

@mandre: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.

[JoelSpeed]

So this prevents the KCMO from getting the platform name for openstack, in turn preventing it setting the external cloud volume plugin for openstack which is desired.

The second effect here is that the ObserveCloudProviderNames historically has been responsible for copying the configmap from the openshift-config namespace to the operator namespace, seems like that's ok for the KCMO/KASO, is anything else using that observer? I know CCMO does the copy manually so that's ok, what does the storage operator do?

[mandre]

The second effect here is that the ObserveCloudProviderNames historically has been responsible for copying the configmap from the openshift-config namespace to the operator namespace, seems like that's ok for the KCMO/KASO, is anything else using that observer? I know CCMO does the copy manually so that's ok, what does the storage operator do?

According to this github code search, it's called only from KAS and KCM operators. I would imagine KAS no longer needs access (although this could break until openshift/kubernetes#1389 lands), I'm less sure about KCM.

[JoelSpeed]

Ack, if that's the case and it's only used by those two, then I'm happy with the change, KCM won't need the configmap anymore

/lgtm

[soltysh]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed, mandre, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• pkg/operator/OWNERS [soltysh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment