Service Specific Async Provision Timeout

[cholick]

Problem

Right now, the platform is responsible for deciding the timeout of service instance creation. This results in the platform choosing a very high value, to support any and all service that might be imagined. Cloud Foundry, for example, uses the value of 7 days (I imagine is to support a broker with a literal human on the other side of the broker API, a service that generated tickets?). Platforms using a value this high means that service provisioners will likely give up, and kill provisioning, long before a week has passed (assuming they have sufficient permissions). In cloud foundry, this means resorting to actions purge-service-instance.

As a service author, I'm often in a much better position to decide what that timeout value should be. For many services, values as short as an hour would be appropriate.

Suggested Solution

• Add a timeout value at the catalog level for a service, which would override the platform's timeout.
• Alternatively, If platform operators have concerns with overriding that value, taking the minimum of the platform and the service specific timeout would also address this concern.

[cholick]

I haven't mentioned async binding, as I haven't really seen a problem there in practice, but that's likely because the feature is newer. In the interest of completeness, it might make sense to include a value for that as well?

[duglin]

I like the idea of providing this hint to the platform since, as you said, not all service brokers will have the same timeout window.

[duglin]

Would you be willing to submit a PR? :-)

[cholick]

Sure, happy to submit a PR.