search

openservicebrokerapi / servicebroker

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

Fetching a service binding does not include service id. #614

Closed eruvanos closed 5 years ago

eruvanos commented 6 years ago

Problem

Request to fetch a service binding does not include any information about the related service. For service brokers providing multiple services they have to identify which service should be called.

While the spec enforces now the service id in last operation for service instances, it does not in last operation for service bindings.
This can be worked around by manipulating the operation string, adding the service id in async responses.

To fetch a specific binding the service broker has either to ...

Better would be to get the service id in the request as a parameter.

Background

I do maintain a python server implementation of the open service broker api. (OpenBrokerAPI) Since a while a go, users mentioned that they would like to host multiple services in one broker. Which is now a feature in the framework, but looks like it is not easily to keep with an upgrade to spec version 2.14.

duglin commented 6 years ago

@eruvanos do you need the plan-id too? Also, note that service-id and plan-id are optional for last-op for instances. So, how do you deal with this when they're not present?

eruvanos commented 6 years ago

@duglin the broker framework requires each service implemented in his own class. So that in this case the plan id is not required because the service id is enough to delegate incoming calls to the right object.

For the last operation of service instances the framework does not use the optional parameters, but add service id on async responses in front of the operation string. On requests to last_operation the operation string is split into service id and original operation string, which was given from the server.

Provision, Update, Deprovision --[if async]--> operation=service-id + 'operation string from service'
Last Operation --> service-id, operation = 'incoming operation string'.split()
mattmcneeney commented 5 years ago

You can now fetch a service instance with GET /v2/service_instances/:instance_id, and the service_id and plan_id information is contained in the response. So as long as you know what service instance the binding is on, you can fetch this information as of v2.14.

Hopefully this will help this use case. Closing this issue, but please let me know if I've missed something and there is still a problem.

eruvanos commented 5 years ago

@mattmcneeney Hi, this does not really solve my issue, but I thing I will drop the multi service feature in the framework to support the new API. It looks like, that the API is developing into a direction, where a multi service implementation becomes harder and harder.

mattmcneeney commented 5 years ago

Reopening this issue following this discussion on Slack.

The ask is for the GET /v2/service_instances/:instance_id and GET /v2/service_instances/:instance_id/service_bindings/:binding_id endpoints to contain two query parameters - service_id and plan_id. This is to support brokers which need to know this information to talk to some other system in order to respond to these requests.

@fmui @jberkhahn any thoughts on this?

jberkhahn commented 5 years ago

Would they be required? Seems like we should have added them in the first place, but it would be nice if those endpoints matched the others, but it might be too late now.

mattmcneeney commented 5 years ago

They would have to be optional now - but I think that's OK. PR inbound!

fmui commented 5 years ago

If they are optional, the broker has to be prepared that they are not provided. This means the broker has to implement retrieving the service and plan ID anyway. Does adding these parameters really provides value?

mattmcneeney commented 5 years ago

It would allow some stateless service brokers to support these endpoints if the IDs were provided

On Tue, 9 Jul 2019 at 15:49, Florian Müller notifications@github.com wrote:

If they are optional, the broker has to be prepared that they are not provided. This means the broker has to implement retrieving the service and plan ID anyway. Does adding these parameters really provides value?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/openservicebrokerapi/servicebroker/issues/614?email_source=notifications&email_token=ABXNJTCFMECG2ZTXZ3TITBTP6SQODA5CNFSM4F7HUAFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZQQFCQ#issuecomment-509674122, or mute the thread https://github.com/notifications/unsubscribe-auth/ABXNJTGC6K3322BO2SI275LP6SQODANCNFSM4F7HUAFA .