You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 6, 2022. It is now read-only.
Received customer request for SQL DB geo-replication. Do we have a plan to support this?
I think it is hard to design the behaviors to fit it into current OSB API Spec.
First of all, it should be another db-only service in OSBA and it is one service instance to manage two (or more) DBs on Azure.
The problem is that, we shouldn't provide only geo-replication DB creation. Failover also needs to be supported (or users need to do out-of-band operations just like what we discussed in #124). It seems that the only choice to support that for now is Update API. But it doesn't totally make sense. A better choice is the in-review new item in OSB API Spec, broker extensions: openservicebrokerapi/servicebroker#431. It takes time to check in. Overall, it is still doable via Update API.
The whole failover process should be unbind->failover->bind->restage the app. So another problem is that, when the primary DB is down, unbinding could fail as the broker tries to delete the user. The failure is expected in such a situation. But, how does unbinding determine whether the failure is expected or not? Per OSB API Spec, there is no additional parameters for unbinding but service_id and plan_id: https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#unbinding.
Any thoughts?
The text was updated successfully, but these errors were encountered:
Received customer request for SQL DB geo-replication. Do we have a plan to support this?
I think it is hard to design the behaviors to fit it into current OSB API Spec.
First of all, it should be another db-only service in OSBA and it is one service instance to manage two (or more) DBs on Azure.
The problem is that, we shouldn't provide only geo-replication DB creation. Failover also needs to be supported (or users need to do out-of-band operations just like what we discussed in #124). It seems that the only choice to support that for now is Update API. But it doesn't totally make sense. A better choice is the in-review new item in OSB API Spec, broker extensions: openservicebrokerapi/servicebroker#431. It takes time to check in. Overall, it is still doable via Update API.
The whole failover process should be unbind->failover->bind->restage the app. So another problem is that, when the primary DB is down, unbinding could fail as the broker tries to delete the user. The failure is expected in such a situation. But, how does unbinding determine whether the failure is expected or not? Per OSB API Spec, there is no additional parameters for unbinding but service_id and plan_id: https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#unbinding.
Any thoughts?
The text was updated successfully, but these errors were encountered: