Skip to content
This repository has been archived by the owner on May 6, 2022. It is now read-only.

Add support for OSBAPI 2.15 #161

Closed
edwardecook opened this issue Jun 30, 2020 · 4 comments
Closed

Add support for OSBAPI 2.15 #161

edwardecook opened this issue Jun 30, 2020 · 4 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@edwardecook
Copy link
Contributor

It would be great to get this client up to date with the current version of the OSBAPI spec (which is now on 2.16). This is an interim step to add support for 2.15.

Below is the list of 2.15 release notes, the plan is to categorise them by whether the work has already been done, work is needed or if it is not relevant to this library.

Feature Current Status
Added a delay to polling response for Service Instance and Service Binding last operations. WORK REQUIRED
Added a Service Offering specific async polling timeout. WORK REQUIRED
Allow a Service Instance context to be updated and add org name, space name, and instance names. WORK REQUIRED
Added list of endpoints to create Service Binding response body. WORK REQUIRED
Add plan_updateable field to the Service Plan object. WORK REQUIRED
Added maintenance info support to Service Plans. WORK REQUIRED
Added request identity header. WORK REQUIRED
Allow brokers to not return parameters when returning a Service Instance or Service Binding. N/A
Restrict Operation strings to 10,000 chartacters in the response body for provisioning or deprovisioning a Service Instance, and binding or unbinding a Service Binding. N/A
Remove character restrictions on names of Service Offerings, and Service Plans. N/A
Allow empty descriptions in the response body for getting the last operations of Service Instances, and Service Bindings. N/A
Added mechanism for orphan mitigation. N/A
Allow brokers to return 200 for no-op update Service Instance requests. N/A
Clarify what happens when deleting during a provision/bind request. N/A
Clarify broker behavior expected when deprovisioning while a provision request is in progress and unbinding while an unbind request is in progress. N/A
Clarify broker behavior when a provision request is received during a provision request for the same instance or when a binding request is received during a binding request for the same binding. N/A
  • DONE = Feature is released
  • ALPHA = implemented behind feature flag
  • WORK REQUIRED = not currently implemented - requires work
  • N/A = no changes required to client

For implementation it would probably make sense to follow the same pattern as for 2.14, #144, i.e. PR in features as Alpha features and once it is all implemented a final PR to move them out of Alpha and add Version2_15 to the client.

Hopefully that sounds reasonable?

@jhvhs
Copy link
Contributor

jhvhs commented Aug 7, 2020

Status update:

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 30, 2020
@jhvhs
Copy link
Contributor

jhvhs commented Nov 30, 2020

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Nov 30, 2020
@mrbobbytables
Copy link

This project is being archived, closing open issues and PRs.
Please see this PR for more information: kubernetes/community#6632

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

5 participants