[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction

[Martin P Pain]

I've added an example/scenario to the page about using separate Automation 
Plans to provide teardown [1] (also included below).

This scenario covers the case where the set-up/use/teardown is done as 
part of an automated script.

This does not write off this as a potential solution, but does raise some 
problems that would need solving if we were to use this approach.

Martin

[1] 
http://open-services.net/wiki/automation/Temporary-deployment:-%22Teardown-plan%22-property-on-Automation-Result/




----------

Here is a copy of the scenario text, but it's better formatted at [1]:

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.

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130711/3fc28eb2/attachment-0003.html>