The sequence diagrams in this topic show you how an on-demand service sets up and maintains service instances. The diagrams indicate which tasks are undertaken by the on-demand broker (ODB) and which require interaction with the Service Adapter.
Register the Service Broker with Cloud Foundry
The following sequence diagram shows the workflow for registering a service broker with Cloud Foundry.
About Creating and updating Service Instances
This section contains diagrams that present the workflow for the following actions:
Create a Service Instance
To create a service instance, users run the cf create-service command. For more information about this command, see Creating Service Instances.
The following sequence diagram shows the workflow for creating a service instance.
There are two ways this process can fail:
-
Synchronously: The Cloud Controller deletes the service according to its orphan mitigation strategy. For more information, see Orphans.
-
Asynchronously: This happens while BOSH deploys the service instance. The Cloud Controller does not issue a delete request.
Update a Service Instance
To update a service instance, users run the cf update-service command. For more information about this command, see Update a Service Instance.
Updates can only proceed if the existing service instance is up-to-date. ODB calls generate-manifest on the service adapter to determine whether there are any pending changes for the instance.
When determining whether there are pending changes for an instance during an update,
ODB ignores any configuration supplied in the update block of the manifest returned by the service
adapter's generate-manifest subcommand.
For more information, see
Update Block
in the Cloud Foundry BOSH documentation.
Update When There Are No Pending Changes
If there are no pending changes, the update proceeds. The manifest from the second call to generate-manifest is deployed.
The sequence diagram below shows the workflow for updating a service instance if there are no pending changes.
Update When There Are Pending Changes
If there are pending changes, the update fails.
The sequence diagram below shows the workflow for updating a service instance if there are pending changes.
Create or update a Service Instance with Post-Deploy Errands
If a user runs the cf create-service command with post-deploy errands configured for the deployment, ODB does not report success to Cloud Foundry until the deployment is created, or updated, and all post-deploy errands complete. For more information about post-deploy errands, see Service Instance Lifecycle Errands.
The following sequence diagram shows the workflow for creating or updating a service instance when post-deploy errands are configured.
Recreate all Service Instances
ODB provides the BOSH errand recreate-all-service-instances. This errand executes a bosh -d DEPLOYMENT-NAME recreate --fix on each service instance (SI) managed by the broker. It is used for triggering low-level BOSH agent certificate re-installation, or for backup and restore purposes, for example in a migration between foundations.
The following sequence diagram shows the workflow for re-creating service instances.
About upgrading Service Instances
This section contains diagrams that present the workflow for the following actions:
-
Upgrade All Service Instances with External Service Instances API Configured
-
Upgrade All Service Instances with Maintenance Information Configured
-
Upgrade One Service Instance with Maintenance Information Configured
Upgrade all Service Instances
ODB provides the BOSH errand upgrade-all-service-instances. This errand upgrades all service instances managed by the broker. This is also used when a plan changes. The errand updates all instances that implement a plan with the new plan definition. For more information, see Upgrade All Service Instances.
The following sequence diagram shows the workflow for upgrading all service instances.
Upgrade all Service Instances with External Service Instances API Configured
If the service instances API is configured, the upgrade-all-service-instances errand connects to a different endpoint to gather the list of instances to upgrade. For more information, see Service Instances API.
The following sequence diagram shows the workflow for upgrading all service instances with external service instances API configured.
Upgrade all Service Instances with Maintenance Information Configured
If Cloud Foundry supports maintenance information and it is supplied in the ODB configuration, the upgrade-all-service-instances errand coordinates with Cloud Foundry to update only service instances that are outdated. If a service instance has already been upgraded successfully, then the errand has no effect on that service instance.
The following sequence diagram shows the workflow for upgrading all service instances when maintenance information is configured.
Upgrade One Service Instance with Maintenance Information Configured
If Cloud Foundry supports maintenance information and it is supplied in the ODB configuration, you can trigger a single upgrade by running cf update-service SERVICE_NAME --upgrade.
The following sequence diagram shows the workflow for upgrading one service instance when maintenance information is configured.
About Binding and Unbinding Service Instances
This section contains diagrams that present the workflow for the following actions:
Bind a Service Instance
To bind a service instance, users run the cf bind-service command. For more information about this command, see Bind a Service Instance.
The following sequence diagram shows the workflow for creating a binding.
Unbind a Service Instance
To unbind a service instance, users run the cf unbind-service command. For more information about this command, see Unbind a Service Instance.
The following sequence diagram shows the workflow for unbinding a service instance.
About deleting Service Instances
This section contains diagrams that present the workflow for the following actions:
Delete a Service Instance
To delete a service instance, users run the cf delete-service command. For more information about this command, see Delete a Service Instance.
The service adapter is not invoked in the delete service workflow.
The following sequence diagram shows the workflow for deleting service instances.
Delete a Service Instance with Pre-Delete Errands
If you run the cf delete-service command with pre-delete errands configured for the deployment, ODB does not report success to Cloud Foundry until all pre-delete errands complete and the deployment is deleted. For more information about pre-delete errands, see Service Instance Lifecycle Errands.
The following sequence diagram shows the workflow for deleting service instances with pre-delete errands configured.
Delete all Service Instances
ODB provides the BOSH errand delete-all-service-instances. This errand deletes all service instances managed by the broker. For how to use this errand, see Delete All Service Instances.
The following sequence diagram shows the workflow for deleting all service instances.
Delete All Service Instances and Deregister Broker
ODB provides the BOSH errand delete-all-service-instances-and-deregister-broker. This errand deletes all service instances managed by the broker and deregisters the broker from Cloud Foundry. For how to use this errand, see Delete All Service Instances and Deregister Broker.
The following sequence diagram shows the workflow for deleting all service instances and deregistering the broker.
Content feedback and comments