openservicebrokerapi / servicebroker

Open Service Broker API Specification
https://openservicebrokerapi.org/
Apache License 2.0
1.19k stars 434 forks source link

General Storage Enhancement in Open Service Broker API #515

Open leonwanghui opened 6 years ago

leonwanghui commented 6 years ago

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:

Thanks for reviewing this proposal, and plz be free to ask if you have any question!

leonwanghui commented 6 years ago

@duglin @pmorie

n3wscott commented 6 years ago

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?

leonwanghui commented 6 years ago

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:

pmorie commented 6 years ago

@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.

leonwanghui commented 6 years ago

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?

leonwanghui commented 6 years ago

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.

mattmcneeney commented 5 years ago

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