Asynchronous provisioning/deprovisioning and update of cf_service_instance

[samedguener]

Dear contributors,
`
during deployment on our production environment, we faced the following issue:

1 error(s) occurred:

* module.storage_services.cf_service_instance.mongodb-deploymentapi: 1 error(s) occurred:

* cf_service_instance.mongodb-deploymentapi: Server error, status code: 400, error code: 10001, message: This service plan requires client support for asynchronous service operations. 

While deployment of a mongodb instance using development service plans is successful, the deployment using production-grade service plans fails. This is due to the production-grade service plan, which disallow the usage of synchronous service instance instantiation at the service broker.

The Open Server Broker API offers more information regarding asynchronous and synchronous provisioning docs.

I proposed a solution for this in #52 In this solution we request the CF API for the status of the created service instance with accepts_incomplete=true enabled as proposed in CF API. We wait until the service instance is started.

If there are any open questions, please free to ask.

Best,
Samed

[gberche-orange]

Thanks @samedguener for this contribution!

The OSB specifications don't mandate a timeout for async operation which can then legitimately take up to several days for some brokers.

Terraform docs suggests that resources can define standard per resource timeouts for the different phases

May be the aws_db_instance resource can provide some inspiration to leverage standard timeout configuration support as well as built-in retries that might avoid blocking sleeps, I ran into this vault retry loop might may provide inspiration ?

This enhancement request was also tracked into #35 @mevansam Do you see other UX changes to consider ?

[samedguener]

Thanks for the fast response!

I would suggest that we use timeouts as they are used in aws_db_instance. So the Terraform Core will be responsible in timing out single functions, while we are polling in an endless loop the CF API for updates.

If you are comfortable with this, I can edit the PR.

Best,
Samed

[gberche-orange]

@samedguener +1 for using the same polling loop pattern than what the aws_db_instance does, leveraging the StateChangeConf helper

[gberche-orange]

@janosbinder the OSB API does support async service instance updates, see https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#updating-a-service-instance

#52 seems to only acceptance test async provisionning and deprovisionning and not yet async updates.

I'm therefore not yet closing it. Please feel free to open a new dedicated issue for "async service instance updates" to carry less history.

Assigning to later milestone as this is not a prereq for 1.0.

[janosbinder]

This feature is provided by #111 . Thank you @samedguener for your initial contribution.