search

cloudfoundry / cloud-service-broker

OSBAPI service broker that uses Terraform to provision and bind services. Derived from https://github.com/GoogleCloudPlatform/gcp-service-broker
Apache License 2.0
80 stars 38 forks source link

Deprovisioning MySQL Service on Azure leaves the servicebroker database in an inconsistent state #9

Closed sujitdmello closed 4 years ago

sujitdmello commented 4 years ago

Running cloud-service-broker serve on my Windows PC using Windows Subsystem for Linux

Provision a new Azure MySQL database instance using the cloud-service-broker client (successfully created in Azure)

Deprovision the above instance (successfully deletes it from Azure)

Provision a new MySQL database instance Expecting a new instance to be created in Azure but instead throws this error on the client: image

Server shows this error: image

Manually delete the entries from the _terraformdeployments table in the servicebroker database using mysql CLI.

Provision a new MySQL database instance (successfully created in Azure)

erniebilling commented 4 years ago

Seems to be related to re-using the same instanceid. This is a bit of a gray area in the spec (see https://github.com/openservicebrokerapi/servicebroker/blob/v2.15/spec.md#provisioning) Caller is responsible for creating a globally unique id and the broker must return a 409 if the instanceid references an existing instance. Nothing said about re-use of an instanceid after a service is destroyed.

sujitdmello commented 4 years ago

Is this uniqueness to allow you to track it later?

mattdot commented 4 years ago

Deprovisioning spec says that "When a Service Broker receives a deprovision request from a Platform, it MUST delete any resources it created during the provision. Usually this means that all resources are immediately reclaimed for future provisions."

That makes it sound like you could re-provision things that were deprovisioned

erniebilling commented 4 years ago

The only "resource" left is a row in the internal database that has captured the successful deprovision.

| tf:ebmysql1: | 2020-02-11 11:08:50 | deprovision | succeeded |

Could update broker to delete that row and re-provisioning with the recycled instanceid would work. No platform is ever going to do this though.

sujitdmello commented 4 years ago

Discussed with Ernie and considering that non-humans will be providing the instance-id, will keep the logic as intended. instance-id should be historically unique so that it can be later tracked. Ernie will look into fixing the error condition and returning a 409 instead.