search

openservicebrokerapi / servicebroker

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

Service dependencies specification #488

Closed fmui closed 6 years ago

fmui commented 6 years ago

See issue #427.

First draft of the service dependencies specification.

cfdreddbot commented 6 years ago

Hey fmui!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA.

n3wscott commented 6 years ago

Overall I think this change does not do enough to allow the ecosystem to play nice together. I understand the use-case but I think this implementation is too opinionated about the solution it recommends brokers to implement. I don't see an easy way for broker to broker dependencies, such as the use case where I want to bring my broker that provisions my application, and that application depends on a database of some kind, it would be real nice to be able to say "in my application broker, please tie in a database that speaks SQL".

I think the customizable parameter targets are confusing. And in the very least they need to be paths inside the json object relative to the root of the object.

It would be interesting to use the concept of adheres_to when specify a generic dep.

I think more detail needs to be added around what the platform is expected to do when it provisions something and the catalog can change with more items, or deprovision and items disappear.

I wonder if there is also a chance to add a concept of a service depending on a binding. At the moment we make bindings but we do not get to say who they are for. But a binding could be shared as well so each binding could have n parties using it. I am not sure on that point...

mhrivnak commented 6 years ago

I agree with @n3wscott 's summary. It would be helpful to focus more on illustrating the big picture and how the key use cases are fulfilled. Reading this proposal, I found it somewhat difficult to keep track of where things fit in to a high-level workflow, and who-or-what is the actor performing each step.

It may help to focus more on addressing these general questions:

  1. What exactly is the mechanism and algorithm for match-making? There are a lot of details to explore around how a Plan (or other resource maybe) would express what it requires and what it provides. It will help to first describe the data and algorithm without talking about API operations.
  2. What component is expected to execute the match-making algorithm to determine which resource fulfills a requirement? Is it always the Platform?
  3. Once some actor determines which resource fulfills a requirement, what then? What specific actions must that actor take? For example, would the Platform be responsible for creating a binding and passing it (along with additional info about the providing service?) to the service being provisioned?
krancour commented 6 years ago

Adding an opinion here that I expressed at the f2f. I believe that solving "adheres to" is a necessary pre-requisite for some of this.

duglin commented 6 years ago

Refresh my memory - what's the status of this? Awaiting an updated PR?