Temporary deployment: "Teardown plan" property on Automation Result

This is one of the original suggested solutions for the Temporary deployment scenarios.

This has since been generalised, but there may still be value in not using the general form, as it makes plan discovery more complicated.

1) One option would be to link from the autoResult to an autoPlan that, when executed, tears down the deployed resource.

Pros:

• v2 clients could consume this, as long as they let the user choose any of the selection dialogs available for autoPlans.
• Could be used for other automation plans available as a result of this deployment, not just tear-down

Cons:

• Doubles the number of resources needed (or more)

Locating plans

It is likely that we would want to find the “teardown” Plan even before the set-up Plan has been executed. There are various issues with this:

• Finding the teardown Plan based on the set-up Plan.
• Knowing what properties will be needed from the set-up Result by the teardown Plan.
• Knowing which parameters in the teardown Plan to pass that data in as.

Here is an example of wanting to find the teardown Plan before execution has been performed:

Actors:

• “Provider”: a service that exposes some form of OSLC-based service administration interface
• “Consumer”: a service that consumes the provider’s interface (but was not written specifically for this provider). Provides a UI and the ability to run scheduled automated processes.
• “User”: a human who uses the consumer’s UI.

Scenario:

1. User creates an automated process definition through the Consumer’s UI.
2. Consumer uses a delegated UI provided by the Provider to allow the user to select a plan exposed by the Provider.
3. User selects a plan.
4. Consumer stores a reference to this selection in the automated process definition.
5. (User may add other plans to the process - e.g. running automated tests that depend on the resource created by the one just selected - but these are not important to this scenario.)
6. User wants to add another plan to the automated process definition, to perform an action on a resource created by the previous one.
7. Consumer uses a delegated UI provided by the Provider to allow the user to select a plan that can be applied to the resource created by the previous one (even though that resource hasn’t been created yet as the automated process has not been executed). (This may or may not be a “teardown” or “uninstall” action.)
8. User selects a plan.
9. Consumer stores a reference to this selection in the automated process definition.
10. Consumer configures the schedule or trigger for the automated process.
11. At a later time, when the user is not present, the Consumer starts the automated process as defined by the schedule or trigger.
12. Provider executes the action, which creates a new resource.
13. Consumer requests the Provider to execute the first plan that was selected.
14. When this is completed, the Consumer requests the Provider to execute the second job/task/plan on the resource created by the first one.
15. Provider executes the action, which may or may not (depending on what plan was selected) delete the resource.

What I do not know how to achieve is step 7 - how does the consumer know that the previous action would create a resource, and how would it select the delegated UI for actions that can be performed on that new resource? Also, how do we make it simple enough for consumer implementations to support these actions that create resources, in addition to the simpler ones that only act on resources that already exist? There is always pressure to just write what’s simplest, but in this case that will affect which providers it can interact with.

Proposal for linking to teardown plan from Result

(note: all property names are up for debate. this proposal focuses on their meanings.)

Add one new property to the AutomationPlan resource:

Add one new relationship to the AutomationResult:

Alternative 1

The properties could be called “mayBeTornDown” and “mayBeTornDownBy” respectivly. (I don’t want to call it “tornDownBy” as that makes it sound like it has already happened). Alternatively the relationship on the Result could be called “teardownPlan” - if the word “plan” can be used to refer to anything that can be executed, not specifically an Automation Plan.

Alternative 2

The property on the Plan could have terms #required and #optional defined which could be used as values. (Where #required means “strongly desired” by the provider - not an absolute “MUST” requirement).

When asking the user if they want to teardown (such as providing a “tear down when finished” checkbox next to the selection of deployment plan) then they could default to checked (i.e. teardown) if #required is used, and unchecked (i.e. no teardown) if #optional is used. But I don’t see it being useful any more than this.

Alternative 3

To try and make this generic to any “subsequent plans” that can be performed on the resulting deployed resource, the property on the Plan could be:

(The term “operation” is used to mean “something executable” without referring specifically to AutomationPlans.)

Then the Result can contain the oslc_auto:teardown (or oslc_auto:mayBeTornDownBy, if we decide to call it that or something else) relationship to the teardown plan, if that is specified in the oslc_auto:resultProvidesOperation property on the Plan.

The result could also contain copies of the oslc_auto:resultProvidesOperation properties for the operations (plans) that are actually available on it. This allows results to provide operations in a way that all clients can consume - they know to look for oslc_auto:resultProvidesOperation - but can also indicate what each one does by using that property to point to well-known (either oslc_auto or extension) predicatessuch as oslc_auto:teardown.

e.g:

_:autoPlan1
    oslc_auto:resultProvidesOperation <oslc_auto:teardown>.

_:autoResult1
    oslc_auto:executesAutomationPlan _:autoPlan1;
    oslc_auto:resultProvidesOperation <oslc_auto:teardown>;
    oslc_auto:teardown <_:teardownPlan1>.

Alternative 4

Use oslc_auto:teardown on the Plan to indicate that teardown will be available (as above), then on the Result point to the teardown Plan using the same mechanism as CM domain uses to point to Actions. (As long as this provides a way to know that it is the teardown Plan that is being pointed to.)