-
Notifications
You must be signed in to change notification settings - Fork 436
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
General Storage Enhancement in Open Service Broker API #515
Comments
I do not understand the usecase. Why would you want to mount a volume to a black box service? If this solving a real problem or just promoting OpenSDS? |
Hi @n3wscott , I prefer to say 'use' volume more than mount volume, since you have to mount it before store data into the file system. And for your question, I think I can explain the reason by introducing the background of our proposed solution:
|
@leonwanghui I think it would be very helpful to have an account in writing of what the goal is in terms of experience provided to the end user. |
Hi @pmorie , thanks for your suggestion, I will update it for sure. Generally the goal is to provide a unified storage management to users cross platforms through OSB API, the use case at the moment are provisioning, snapshot, data replication, data migration and data lifecycle. And normally people would ask why we don't integrate into Kubernetes through CSI, and the answer is CSI can't meet the requirement of customized features from customers, and we want to provide an elegant way to integrate into Kubernetes seamlessly. Meanwhile, we want to bring these enhancements back to OSB API, wishing the storage parts related to Kubernetes could be improved. @pmorie Does that make clear to you? |
Hey @leonwanghui - is this still something that is of interest to you? If so, I believe there may be some extensions to the binding response objects that you may wish to propose for profile.md Thanks |
Background
It's well known that storage is always a hot topic in cloud platforms, because data management is the most complicated part in cross-platforms. And that's exactly the major targets that OpenSDS aims to solve.
Solution Description
A detailed introduction about the proposed solution is available at here.
Benefits to Users
By decoupling volume scheduling feature for external storage from pod life-cycle management in the way of bypassing current PV/PVC mechanism in k8s, users can benefit a lot in these scenarios:
In Private Cloud or Hybrid Cloud scenario, it’s difficult for Kubernetes Admin to perceive and configure the storage class exposed by storage providers, but with Service Catalog these storage service classes can be integrated into Kubernetes API seamlessly without any impact to k8s current framework.
Feedback to OSB API
From the spec I found that there are few words to declare storage service and we do have a large opportunity to enhance it. There are some feedback below about how to provide block volume service to Kubernetes.
Binding
Currently from the spec there is no guidance for Service Catalog to provide block volume service, but according to our solution, there would be some changes as follows:
More to come
Currently a lot of features (such as data replication, data protection, data migration, etc) are under development, we will add more feedback after finishing new features.
Thanks for reviewing this proposal, and plz be free to ask if you have any question!
The text was updated successfully, but these errors were encountered: