Closed staebler closed 6 years ago
In CF, we send the original plan ID as we cannot be sure that the operation has completed successfully. Hopefully this is what your broker expects @avade
Can anybody add what happens today in the kubernetes world?
Currently in kubernetes service-catalog, the new plan ID is sent in the last operation request.
If the update fails then the new planID would have no meaning to the instance, so it seems like we have no choice but to use the old one. But either way we should clarify which is to be used in the spec.
If the update fails then the new planID would have no meaning to the instance, so it seems like we have no choice but to use the old one. But either way we should clarify which is to be used in the spec.
I agree. On the other hand, once the plan update is successful, the broker may not be able to find the instance using the old plan ID.
I think we need a new acronym.... SEW (screwed either way) :-)
Can someone let me know what service-catalog does in this scenario? @pmorie @vaikas-google etc
@mattmcneeney Currently in kubernetes service-catalog, the new plan ID is sent in the last operation request.
Oh fun. That means we have inconsistent behaviour across CF and service-catalog, so we should aim to resolve this quickly as this means service brokers do not know what they should expect to receive from different platforms.
@avade Does the on-demand service broker do anything with the plan_id
we send on the last_operation
request?
Other service broker authors; do you use this field? And if so, what do you use it for? cc @fmui @vaikas-google
For an asynchronous plan update on an instance, which plan ID should be used for last operation requests? Should it be the ID of the plan to which the instance originally belonged? Or should it be the ID of the plan to which the broker is in the process of moving the instance?