Support for sharing service deployments/subscriptions across service instances (e.g distinct OSB CF client)

[gberche-orange]

As a service-user making use of coab through distinct marketplaces (e.g. distinct CF instances), in order to have multiple apps sharing the sharing the data data, I need to be able to share service deployments (e.g. a bosh cf-mysql-deployment + its database subscription).

Possible UX

Similar to multi region service offerings such as https://docs.pivotal.io/p-cloud-cache/1-7/WAN-bi-setup.html

CF deployment 1:

cf create-service cf-mysql default -c {'shared-instance-id=guid'} instance1
#wait for the service instance to finish provisioning
cf service 
#bind service to app

CF deployment 2:

cf create-service cf-mysql default -c {'shared-instance-id=guid'} instance2
# rejects the request in case of inconsistent service plan/params with instance 1
#wait for the service instance to finish provisioning
cf service 
# finishes early, as coab detects the existence of a shared cluster.
#bind service to app

The service binding UX; service binding on both instance1 and instance2 return a URI to the same bosh deployment, with distinct credentials.

The update UX (service plan, parameters, name): both instances can be acted upon, sequentially, acting on the shared bosh deployment. User attempts to update the shared-instance-id param are rejected.

Limitation: updates made in instance 1 on data cached by the cloudcontroller (service name, service plan) will not be reflected on instance 2

The unprovisionning UX:

• A delete service instance decrements the number of references to the shared deployment
• When the number of references to the shared deployment equals zero, the deployment is deleted by coab.

Possible impl

This is similar to similar to the peripli design documented at https://docs.google.com/document/d/1Zhs29cseL580jLdyfQc3Gns5Rti6aj7XWFW0mWK657U/edit#heading=h.b8m5mqmo5mw8

Service-reference entity

COAB maintains a new entity "service-reference" in paas-template git repo. Attributes:

• service instance guid (primary key)
• shared-instance-id
• OSB meta-data:
  • X-Api-Info-Location
  • org/space/user id & name

Storage is abstracted into a ServiceReferenceRepository interface.

• initial storage could be a yaml file in the templates repo, e.g. coab-depls\reference-<shared-instance-id>.yml

SharedServiceInstanceProcessor

A new BrokerProcessor in the pipeline applies the following behavior:

• preCreate:

  • when param shared-instance-id is specified, then
    • create a new service reference
    • look for a service instance with id shared-instance-id
    • if one match, then
      • if CSIR matches the current service instance (recorded in coab-vars.yml), i.e. matches service plan and service parameters (and ignoring CF profile meta-data), then set synchronous provisionning completion in CSIR, and skip BoshProcessor (i.e. clear CRSI)
      • otherwise return an error listing current service plan and service params
    • if none, then mutate the CreateServiceInstanceRequest in the context by replacing the service-instance-id with shared-instance-id

• preUpdate:

  • when param shared-instance-id is specified, then
    • lookup service reference with id service-instance-id
    • if one match, then
      • check that that pointed bosh deployment has the same shared-instance-id param in coab-vars.yml, otherwise reject the update request synchronously with message shared-instance-id param is immutable, it can't be changed
    • mutate the UpdateServiceInstanceRequest in the context by replacing the service-instance-id with shared-instance-id

• preDelete:

  • when param shared-instance-id is specified, then
    • lookup service reference with id service-instance-id & delete it.
    • find all remaining service references with id shared-instance-id
    • if one match, then set synchronous unprovisionning completion in DSIR, and skip BoshProcessor (i.e. clear DSIR)
    • if none match, then mutate the DeleteServiceInstanceRequest in the context by replacing the service-instance-id with shared-instance-id

Get Service Instance

Implement the Fetching a Service Instance endpoint so that modified params in instance 1 is visible in UIs when displaying/updating instance 2.