Service Instance Relationship for Provision (Nested provisioning)

[meip]

Problem

As a Service Provider I want to be able to reuse another Service Instance for a new Service Provision request through OSB so that the end user can request nested instances on his own behalf.

Examples

Service Provider for a dedicated MySQL Cluster (RDBMS) so that a customer can provision n clusters. Further the customer should be able to provision n schemas on top of one of these clusters and also do bindings. This would lead to the following steps:

1. Catalog Item A provisions a Cluster
2. After Cluster provision the user should be able to provision further Schemas on that Cluster, which would mean that the catalog “dynamically” gets “Catalog Item B which provisions schema on the previous cluster”
3. After the schema is provisioned the regular bind as it is today for a simple MySQL Service Instance should follow

Details

Extend the Service Instance object with a parent<->child relationship of Service Instance.

Parent reference

To reference the parent the instance guid is used. OSB won't be able to validate it further and has to trust the platform for a valid reference (in terms of accessibility).

Proposal

Workflow - Create Service with child and existing parent

1. cf create-service ServiceA PlanA service-instance-a
2. cf create-service ServiceB PlanB service-instance-b -c '{"parentReference": "service-instance-a-guid"}'

Deprecated Workflows (as of 12th of March 2018)

The following workflows are deprecated because parentAlias has been declined.

Workflow - Create Service with child and non-existing parent

1. cf create-service ServiceB PlanB service-instance-b -c '{"parentAlias": "service-instance-a"}'
2. // Job gets queued with a TTL and provision for child continues when parent exists
3. cf create-service ServiceA PlanA service-instance-a -c '{"alias": "service-instance-a"}'
4. // After parent success, child gets provisioned as well

Worflow - parentAlias validation

1. cf create-service ServiceA PlanA service-instance-a -c '{"alias": "service-instance-a"}'
2. cf create-service ServiceB PlanB service-instance-b -c '{"parentAlias": "service-instance-a"}'
3. // parentAlias is validated if the the child is in the same Context as the parent instance
   (Optional) further this validation could also be supported by the Schema Object

Links

• OSB Spec Discussion
• Microsoft Azure Broker PoC

[mcelep]

Some remarks about the alias: It would be nice if the broker did not do CF specific stuff so that it can also be used from Kubernetes. Mentioning this due to the description:

The alias should be context scoped. This means the alias must be unique within a distinct context (i.e. Cloud Foundry Organization and Space).

Moreover, haven't really thought about it in detail, but alias uniqueness might be affected by the fact that services can be shared across spaces and organizations.

[meip]

@mcelep sorry I missed to update the proposal on with our latest decisions. We had the same thoughts and decided to only reference by guid. This should also allow the shared across spaces and organizations use case.

[meip]

Implemented in #54