Allow parameters for deprovisioning an instance

[jakkahub]

If deprovisioning an instance required some input parameters or a payload, there is no option. Some service instances may need some parameters for delete, similar to provisioning. Our cloud services need a payload to delete and we are looking for this option.

[pmorie]

I'd really like to know more about this use-case. This is likely not easy to implement on some platforms.

[jakkahub]

We have a service manager that can provision/deprovision services on our cloud platform. We are extending our service manager operations to CloudFoundry with an Open Service broker. Cloud Foundry user can provision/deprovision our services through Open Service Broker API.

Deprovision a service on our cloud platform needs a payload that contains some service specific parameters.

When a CF user delete our service instance from CloudFoundry, CF calls our OSB api DELETE /v2/service_instances/:instance_id However, CF user cannot pass a payload or some parameters to it.

We are looking for something like this:

cf delete-service SERVICE_INSTANCE [-c PARAMETERS_AS_JSON]

$ curl 'http://username:password@broker-url/v2/service_instances/:instance_id?accepts_incomplete=true
  &service_id=service-id-here&plan_id=plan-id-here -d '{
  "parameters": {
    "parameter1": 1,
    "parameter2": "foo"
  }
}' -X DELETE -H "X-Broker-API-Version: 2.12" -H "Content-Type: application/json"

[duglin]

are those parameters specific to your platform, the org/space, or the service instance?

[jakkahub]

Yes, those parameters are specific to our service instance.

Example:

"parameters": {
  "dbaName": "string",
  "dbaPassword": "string",
  "forceDelete": true,
  "skipBackupOnTerminate": true
}

We are trying to find way for CF user to send them to open service broker from CloudFoundry client.

[duglin]

I have my doubts that we'll be able to do this because some HTTP servers can't deal with DELETEs having bodies very well, which is why we put the Context header as a header instead of into the Body. Any reason why you can't put them as extra URL query parameters? For a DELETE that's really the only (best) spot to put "extra stuff".

[jakkahub]

How can I pass extra URL query parameters to broker endpoints? CF is calling the broker endpoints here.

[duglin]

That's a CF question, not a spec question. You'd have to see if the CF folks would be willing to extend the CLI to allow for extra info to be passed in that would then be placed as query parameters on the delete.

[pmorie]

I am not at all sure we have a good way to do this in k8s either.

On Sun, Sep 24, 2017 at 8:26 AM Doug Davis notifications@github.com wrote:

That's a CF question, not a spec question. You'd have to see if the CF folks would be willing to extend the CLI to allow for extra info to be passed in that would then be placed as query parameters on the delete.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/openservicebrokerapi/servicebroker/issues/319#issuecomment-331706864, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWXmCw0eYMQuLQzzbIeTsvYKyHAlfH1ks5slkpbgaJpZM4PdMiT .

[mattmcneeney]

I have followed up with @jakkahub on the cf-release issue. Closing this one.

[Kiemes]

@mattmcneeney Do you still remember what the solution to this problem was? The linked issue is not visible anymore. We would have the same question or similar use case. Is it ok to add more request parameters to the delete request? Or would that not be compliant with the OSBAPI spec? Adding should still be compatible, right?

[mattmcneeney]

@Kiemes I can't quite remember to be honest. I believe the recommended option was to add additional information using headers but that would fall outside the scope of the specification. cc @Samze in case you remember anything on this one!