-
Notifications
You must be signed in to change notification settings - Fork 84
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
Fix last op endpoint unbind response #765
Conversation
pkg/broker/broker.go
Outdated
return nil, false, err | ||
err = cleanupUnbind(&bindInstance, &serviceInstance, a.dao, true) | ||
} else { | ||
err = cleanupUnbind(&bindInstance, &serviceInstance, a.dao, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we should remove the if else and just call cleanupUnbind
and pass in the bind creds to cleanupUnbind
and do the nil check in that method. I think that might be more clear what that is doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah sounds good to me.
pkg/broker/broker.go
Outdated
} | ||
if jobInProgress { | ||
log.Infof("Unbind requested for instance %s, but job is already in progress", instance.ID) | ||
return &UnbindResponse{Operation: jobToken}, false, ErrorDeprovisionInProgress |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading it correctly, I think the handler needs to be augmented to understand this error and make sure it results in the correct response.
There's also a potentially difficult question to answer, which is: we know there is a job running, but is it executing asynchronously? If yes, the response should be a 202. If not, I don't think the spec is very clear. Maybe the best response in that case would be 400. Here is what the proposed spec changes say:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Ive added logic to the handler to check the error but I think returing 202 regardless of async or not is appropriate since the job in running and it will force the client to poll last op endpoint for the result. This meets the spec 202 MUST be returned if the unbinding is in progress.
which in this case it is.
This logic is also used for the deprovision handler
Is this considered complete and ready for review / merge? The PR message still states it's not ready, I might have missed something though. |
@eriknelson ready for review yes, dont think its ready for merge yet |
Ready for review
Changes proposed in this pull request
Which issue this PR fixes (This will close that issue when PR gets merged)
fixes #709