openservicebrokerapi / servicebroker

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

How to extend more service binding operations? #631

Closed Zhaojing-Wang closed 5 years ago

Zhaojing-Wang commented 5 years ago

Explain the terms I will use below: application:The system used to carry the user's own business. On the platform, the code of an application is deployed to servers provided by platform. OSB API:Abbreviation of the open service broker API

As a platform I provide the loadbanlancer service that supports the OSB API. Loadbanlancer needs to mount the user's server for load balancing. In my opinion, the binding operation binds a service instance of loadbanlancer to the user's application. At this moment, there may be none servers mounted with the instance of loadbalancer service. After the user's application is published to the servers, it may be necessary to call the loadBanlance OSB API to mount these servers to the instance of loadbanlancer service. In this case, the OSB API may not have a proper method of operation. I came up with two solutions:

  1. Use the update method of the service instance with different parameters to distinguish whether modifying the attributes of the loadbanlancer itself or mounting the servers to the loadbanlancer service instance;
  2. Extend the service binding with a new operation, such as adding a schema definition to the catalog that modifies the server mount relationship.

I want to know what is best practice to solve this situation when using the OSB API. And when considering about the OSB API V3 standard, how do you think about supporting such a situation?

leonwanghui commented 5 years ago

IMO it's a good proposal, we also have this requirement in block storage service:

OSBA Operation Storage Operation Support
Provision Create Volume ✔️
Bind Create Volume Attachment (target side) ✔️
Unbind Delete Volume Attachment (target side) ✔️
Update Resize/Update ✔️
Deprovision Delete Volume ✔️
? Attach/Mount (host side) ?
? Detach/Unmount (host side) ?

BTW, I think maybe it's more appropriate if we could add Update Service Binding interface to perform additional operations on service binding, @Zhaojing-Wang is that reasonable for you?

Zhaojing-Wang commented 5 years ago

IMO it's a good proposal, we also have this requirement in block storage service:

OSBA Operation Storage Operation Support Provision Create Volume ✔️ Bind Create Volume Attachment (target side) ✔️ Unbind Delete Volume Attachment (target side) ✔️ Update Resize/Update ✔️ Deprovision Delete Volume ✔️ ? Attach/Mount (host side) ? ? Detach/Unmount (host side) ? BTW, I think maybe it's more appropriate if we could add Update Service Binding interface to perform additional operations on service binding, @Zhaojing-Wang is that reasonable for you?

It's a good choice. But I want to discuss more about service broker actions. From my understanding, my scenario may could be supported by using service broker actions. Is there more information about service broker actions?

fmui commented 5 years ago

@Zhaojing-Wang the Generic Extensions PR is #431. But it turned out that it is difficult to implement. There is currently a new initiative going on to design a simplified approach. But there is no new PR, yet.

Zhaojing-Wang commented 5 years ago

@Zhaojing-Wang the Generic Extensions PR is #431. But it turned out that it is difficult to implement. There is currently a new initiative going on to design a simplified approach. But there is no new PR, yet.

@fmui Could you talk more about the details of this new initiative? Or where can I see more information about the initiative?

fmui commented 5 years ago

@Zhaojing-Wang We will discuss this in the OSB calls and when there is tangible proposal, we will publish it.

mattmcneeney commented 5 years ago

Hey @Zhaojing-Wang We will be talking more about the Generic Extensions #431 proposal on today's call. I'm going to close this issue for now and I hope you get involved in the #431 discussions as your input would be very valuable!