[Oslc-Automation] Automation plan relationships and the teardown scenario

[Martin P Pain]

This is my summary of the proposal:

1. For automation plans that create resources (e.g. deployment plans that 
can deploy a new instance of something, e.g. into the cloud), that new 
resource is  identified by the oslc_auto:produced property on the 
AutoResult.

2. That new resource can be passed in to other plans. Those plans are 
identified by the oslc_auto:reversionAutomationPlan  and 
oslc_auto:sequentialAutomationPlan  properties on the AutoPlan that caused 
the creation of the AutoResult in the previous point.

oslc_auto:reversionAutomationPlan is single-valued, and point to the plan 
to "tear down" or otherwise clean up the produced resource.

oslc_auto:sequentialAutomationPlan is multi-valued, and points to the 
plans that use the produced resource

3. Consumers can know what to expect before the plan is executed, using 
the oslc_auto:produces property on the AutoPlan (which identifies the type 
of the produced resource), as well as by the fact that the related 
automation plans are linked from the plan not the result.

--

My view of the sequential automation plan relationship ion this context is 
that it lists all the plans that the provider intends to be applicable to 
executing "on" the produced resource. When constructing an orchestrated 
plan, the precise order is stored separately (so that the same plan can be 
part of multiple orchestration plans/flows/pipelines).
If a consumer who created the automation request knows when the produced 
resource is no longer required, it should call the reversal plan when the 
produced resource is no longer required. (For example, if it needs a 
deployment for a specific program execution, when that execution has 
completed it would then call the reversal plan as the need for the 
deployment has passed.) 
There are also "oslc_auto:relatedAutomationPlan" and "
oslc_auto:parallelAutomationPlan" properties to cover other relationships 
between plans. (These may not take the produced resource in as a 
parameter, unlike the sequential and reversal plans).

Martin




From:   Michael F Fiedler <fiedler at us.ibm.com>
To:     oslc-automation at open-services.net, 
Date:   14/08/2013 15:31
Subject:        [Oslc-Automation] Automation plan relationships and the 
teardown        scenario
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



As the result of some side "interested parties" discussions around the 
teardown scenario (and to a lesser extent, the orchestration scenario),  a 
proposal [1] has been put forward to define some new automation OSLC links 
which describe relationships between different automation plans.   There 
has been some further discussion that these link types might also be 
applicable on automation results.

We'll discuss this proposal in tomorrow's workgroup meeting.   If you have 
a chance, please review the proposal and example usage.

[1] - 
http://open-services.net/wiki/automation/Automation-Additional-Relationships-Proposal/



Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net



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/20130814/932fd7bf/attachment-0003.html>