Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stage or Remove the OpenStack Cloud Provider #80041

Open
andrewsykim opened this issue Jul 11, 2019 · 10 comments

Comments

@andrewsykim
Copy link
Member

commented Jul 11, 2019

What would you like to be added:
As part of a long running effort to remove all in-tree cloud providers, we either deleted or staged the in-tree cloud providers in k8s.io/legacy-cloud-providers. OpenStack was not deleted or staged because of it's internal dep to pkg/util/mount. We should either continue refactoring work for pkg/util/mount so we can stage the open stack cloud provider as well or just remove it.

Why is this needed:
See KEP remove all in-tree cloud providers.

@andrewsykim

This comment has been minimized.

Copy link
Member Author

commented Jul 11, 2019

/sig cloud-provider
/sig openstack
/area code-organization

@dims

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

We should remove openstack cloud provider. @davidz627 and @ddebroy are trying to get CSIMigration to Beta in 1.16, So this removal can be done in 1.16 itself.

@andrewsykim

This comment has been minimized.

Copy link
Member Author

commented Jul 11, 2019

@dims

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

Please see #67782 (comment) for additional context. I've been waiting for this for a while! :)

@davidz627

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

@dims I'm not sure how removal can be done in 1.16 follows from CSIMigration to Beta in 1.16. Are these related? The actual "removal" of in-tree plugin code from a storage CSI Migration timeline perspective is outlined in this doc: https://docs.google.com/document/d/16h9vLLbqQCN83KnlPtn7qL_GB1TYwhWkoA5G4FS3KBI/edit?usp=sharing

@dims

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

@davidz627 When we have the CSIMigration enabled in 1.16, folks will be able to continue using their existing cinder yaml(s) right? that was the thing that is blocking removing all the openstack related in-tree code.

@davidz627

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

It will be beta and off by default. Please see doc for timelines.

TL;DR: You can't remove in-tree code until there is a viable CSI alternative that slots into the backend with CSIMigration with no/minimal user disruption. This requires things like driver feature parity, driver deployed by default, etc.

@andrewsykim

This comment has been minimized.

Copy link
Member Author

commented Jul 11, 2019

/priority important-longterm
/assign @dims

@adisky

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

@dims We are working on the feature parity for both drivers, yet a rigorous testing needs to be done after migration flag enabled. We are not testing every features of cinder csi driver (e2e testing in progress). Apart from that most important thing, we do not have any deployment strategy for csi driver.

@dims

This comment has been minimized.

Copy link
Member

commented Jul 16, 2019

@adisky Agreed. +1 to "rigorous testing needs to be done after migration flag". yes for the "deployment strategy" we just follow what ever the CSIMigration folks come up with (or the sig-storage folks in general). it's not a openstack/cinder specific problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.