I believe the issues with this are: There's no way for the orchestrator to know that the two plans are linked in this way. Even if the user was happy to link them manually, there's still no way that someone implementing an orchestrator would know to consider this relationship based solely from looking at the spec. (It's worth considering that in some cases - e.g. with a test automation suite rather than orchestration - the user may simply want to select a type of resource that the automated script they're preparing depends on, and then the automation system manages the deployment and teardown. I expect the automation system will perform something like this in the background, but it's worth bearing this in mind). "it can find the reference in the result contributions to the deployed environment" - if there are multiple contributions in the result, then how does it know which one to use? e.g. there may be a log in addition to the deployed resource. Should it use all of them? If there are multiple input parameters on the teardown plan, how does the orchestrator know which one to use? I would expect it to be a required parameter, and I would not expect in most cases for there to be any other required parameters - but still if this is the means to determine the input parameter to use, it needs to be officially decided & included in the spec/primer.
So I expect we would need to add: a property for deployment automation plans to use to point to their teardown plan a means to determine which contribution is the deployed resource (I do not know whether this would be better being a change to the RDF or just defining in the spec some means for determining it using existing properties, etc) a means to determine which input parameter that resource should be passed in to (again, this may be done by a change to the RDF used, or using existing ones, e.g. "the only required property" although that may be overly restrictive). Martin From: Michael F Fiedler <[email protected]> To: [email protected], Date: 19/07/2013 14:54 Subject: Re: [Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction Sent by: "Oslc-Automation" <[email protected]> I've been thinking about the scenario some and not sure I am grok-ing the intricacies of how the human/orchestrator/automated script interactions affect the flow. If I think about things from purely a V2 specification point of view, I distill it down to the following flow. 1. 2 Automation plans are created before anything else happens: a) a Deployment plan which creates the new resource b) a Teardown plan which, at run time, needs to know where the new resource is when a Request to execute it is created. The Teardown plan defines an oslc_auto:parameterDefinition with a range of oslc:Reference which represents the resource to be torn down. 2. The user (sitting at the orchestrator) selects the Deployment plan and selects the Teardown plan to be executed when teardown needs to happen 3. At some point the orchestrator (or automated script) creates a request for the Deployment plan. It runs to completion and the AutomationResult contains an oslc_auto:contribution with a URI (or other appropriate representation) reference to the new resource representing the deployment. 4. Now teardown time comes around. Here's an important assumption that may not be true: the orchestrator either tracked the progress of the execution of the request in step 3 and stored the result, or at teardown time (now) issues an OSLC query to find the AutomationResult for the deployment it needs to teardown. With the result in hand, it can find the reference in the result contributions to the deployed environment. 5. The orchestrator creates an AutomationRequest for the Teardown plan and supplies an oslc_auto:inputParameter which is the URI reference to the deployed resource. The teardown request is then executed on the resource. As I said, I believe I'm missing or over-simplifying something here. This might be something we could set up a side discussion on for anyone in the workgroup interested in participating. Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170 "Oslc-Automation" <[email protected]> wrote on 07/16/2013 08:14:23 AM: > Martin P Pain <[email protected]> > Sent by: "Oslc-Automation" <[email protected]> > > 07/16/2013 08:14 AM > > To > > [email protected], > > cc > > Subject > > Re: [Oslc-Automation] Temporary deployment solutions - tear-down > plans - locating the plans in automated script construction > > After we went through this last week at the meeting, has anyone had > a chance to think about this any more? > > The question is: given a deployment Automation Plan that results in > the creation of a new resource, how can the creation of an automated > (orchestration) script tie together the deployment and tear-down of > that resource? Any URI that that resource has is not available at > the time of automated script creation, only execution. And even at > execution time, how can a generic orchestration client know how to > find that URI and how to provide it to the teardown process? > > See the link below for the full scenario. > > Martin > > > > > From: Martin P Pain/UK/IBM@IBMGB > To: [email protected], > Date: 11/07/2013 15:27 > Subject: [Oslc-Automation] Temporary deployment solutions - > tear-down plans - locating the plans in automated script construction > Sent by: "Oslc-Automation" <[email protected]> > > > > 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 > _______________________________________________ > 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 > _______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net _______________________________________________ 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
