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
