Skip to content

add instances_retrievable and bindings_retrievable to service catalog configuration#39

Open
ydkn wants to merge 2 commits intocouchbase:masterfrom
ydkn:add_retrievable_options_to_service_catalog
Open

add instances_retrievable and bindings_retrievable to service catalog configuration#39
ydkn wants to merge 2 commits intocouchbase:masterfrom
ydkn:add_retrievable_options_to_service_catalog

Conversation

@ydkn
Copy link
Contributor

@ydkn ydkn commented Jul 1, 2020

Since the broker actually supports fetching instance and binding parameters it should also allow to communicate that to the outside world.

Otherwise cf curl /v2/service_instances/:instance-id/parameters does not work because CF is thinking that it is not supported.

@spjmurray
Copy link
Contributor

Not in v2.13 it doesn't https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md :D

I guess your actual request here is to support 2.14, 2,15 etc. at which point this is a far bigger request than adding in 2 fields to a struct.

@ydkn
Copy link
Contributor Author

ydkn commented Jul 1, 2020

Thanks for pointing that out. I didn't expected/see that the spec actually has that large changes between minor versions.

But if the broker actually provides only features of v2.13 then there is also no need to provide the GET /v2/service_instances/:instance_id endpoint which is currently implemented - it was added in v2.14

Maybe there is a possibly to add features step by step of newer versions of the spec instead of providing the full feature set of new versions at once.
I'm not sure about the Service-Catalog (I would expect a similar behaviour) but CF also does not really check the API version it just checks the actual feature flags. So providing instances_retrievable is enough to allow CF to query the GET /v2/service_instances/:instance_id endpoint.
To provide also bindings_retrievable there needs to be also the endpoint to fetch the service binding to be implemented.

As far as I currently understand it: Adding instances_retrievable is currently already as a complete feature available since the corresponding endpoint exists - so maybe we can at least add that part?

@spjmurray any thought on how to move up the API version chain?

@spjmurray
Copy link
Contributor

spjmurray commented Jul 2, 2020

In short there is no easy way, beyond some hardcore engineering effort. I've opened feature enhancement #45 to this end. I anticipate implementing only 2.14 for the first pass in August, then after the hard bit is done, 2.15 and 2.16 should be fairly simple incremental updates going into September.

I'm not going to bend the APIs because if my test team saw it they'd complain and stop my fun 😸 But yes, I'm committing to getting to that point where you have those fields -- officially -- fairly soon. You can always do a quick fork in the near term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants