Extended scenario: tear-down of orchestrated/composed deployment

This is an extended scenario of Temporary deployment scenarios

This section is to discuss how tear-down works when the deployment is composed of multiple automation plans, with arbitrary dependencies between them, possibly from multiple providers.

This scenario is likely to only work if all the component plans have the ability to be torn down.

The orchestrator should know how to tear down the component plans that it set up. However, the problem comes when another client registers that it is using one of those component auto results that the master plan set up.

So the problem scenario goes something like this:

• Client A asks provider 1 (the orchestrator) to deploy the master plan.
• Provider 1 (the orchestrator) wants to start auto plan A on provider 2, but that has a dependency on auto plan B on provider 3
  • (the fact that auto plan B is used to fulfil this dependency is most likely controlled by the orchestrator, and may be represented in auto plan A as in the Automation plan configuration data scenario or may not be represented there at all and may be the result of manual configuration in the master plan).
• The orchestrator asks provider 3 to start auto plan B, which results in the creation of auto result B.
• When that has completed, the orchestrator asks provider 2 to start auto plan A, which results in the creation of auto result A.
  • The orchestrator somehow marks that auto result A dependsOn auto result B. (Exactly how this happens can be discussed.)
  • The orchestrator may or may not have needed to pass in information from auto result B, depending on the nature of the dependency.
• Another client, client B, sees auto result A and registers itself as a user of that result.
• Some time later: Client A indicates to the orchestrator that it is finished with the master plans result, so it can be torn down.
• The orchestrator performs its tear down procedure, with the following results:
• Auto result A (the main component, which depends on auto result B, and which client B is using) should not get torn down until client B has indicated that it is finished (i.e. deregistered its interest)
• Auto result B (the dependency) should not get torn down until auto result A has been torn down (i.e. has finished it) because of the dependsOn relationship form auto result A.

I’ve left the last few points abstract as the what the required result is, rather than how this would be achieved, as there are multiple ways in which this could be done. It is not necessarily the orchestrator who has the responsibility of achieving the behaviour stated, but it may be - this will come out o the discussion of how it is achieved.

(In this diagram I’ve treated the create request/lookup result actions as synchronous, when in reality they are not (or are not necesserily), in the hope that this more simply communicates the intent of the diagram.)

One particular thing to consider is mixes of OSLC automation spec versions implemented by the different clients and providers (although anyone using or providing tear down must be using v3) and also if areas/profiles/modules of the spec (like supporting or consuming multi-use, or supporting or querying the dependsOn property) are optional, then can this scenario still work with certain providers unaware of those behaviours? (e.g. it would be preferable if any providers could be used by an orchestrator, even if they do not support dependency mapping - although I’m not sure if this is possible. Hopefully all providers would support tear-down if it makes sense in their product’s area.)

Issues

• provider-to-provider or deployed resources-to-deployed resource relationship (dependsOn) modelling
• What to do about tearing down a composite/orchestrated deployment if not all of the component plans’ providers support teardown? Leave it up to the orchestrator to decide?