Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronous response to client who advertises accepts_incomplete #10

Open
jim-minter opened this issue Dec 4, 2017 · 3 comments
Open

Comments

@jim-minter
Copy link

I think that reading the spec, it is permitted (implementation specific) for a broker with asynchronous capabilities to decide to send a synchronous provision/deprovision response to a client, regardless of whether the client advertises accepts_incomplete or not. I think that at the moment osb-checker doesn't bear this in mind.

@leonwanghui
Copy link
Collaborator

@norshtein @zhongyi-zhang Any thought?

@zhongyi-zhang
Copy link
Collaborator

That's true. But I think the checker does allow async or sync response.
Provision: https://github.com/openservicebrokerapi/osb-checker/blob/master/2.13/tests/test/test.js#L237
Deprovision: https://github.com/openservicebrokerapi/osb-checker/blob/master/2.13/tests/test/test.js#L501
And async bind is not yet supported in OSB API 2.13.

Is there anything I missed?

@leonwanghui
Copy link
Collaborator

From my perspective, here is the current sync/async support matrix:

Broker Support Config accept_incomplete Result
async sync false -
async async true ✔️
sync sync false ✔️
sync async true ✔️

So I think what @jim-minter trying to express is we should support the first option because logically it's right but according to spec Service Brokers that cannot guarantee completion of the operation with the response SHOULD implement the asynchronous response, IMO it's broker authors' duty to guarantee the consistency between broker capabilities and config file.

Any thought?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Inbox
Development

No branches or pull requests

3 participants