Open leonwanghui opened 6 years ago
@duglin @pmorie
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?
Hi @n3wscott @pmorie @duglin , I have updated this design proposal with adding some benefits to users, please take a review at it, thanks!
BTW, if any question you have with this design, please be free to ask, and we can discuss it on weekly meeting.
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:
BindResource (hosted in Bind request)
VolumeMount (hosted in Bind response)
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!