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 <[email protected]> To: [email protected], Date: 14/08/2013 15:31 Subject: [Oslc-Automation] Automation plan relationships and the teardown scenario Sent by: "Oslc-Automation" <[email protected]> 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 [email protected] 919-254-4170_______________________________________________ Oslc-Automation mailing list [email protected] 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
