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

[Michael F Fiedler]

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
fiedler at us.ibm.com
919-254-4170

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
07/16/2013 08:14:23 AM:

> Martin P Pain <martinpain at uk.ibm.com>
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 07/16/2013 08:14 AM
>
> To
>
> oslc-automation at open-services.net,
>
> 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 at IBMGB
> To:        oslc-automation at open-services.net,
> 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"
<oslc-automation-bounces at open-services.net>
>
>
>
> 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
> 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
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130719/28b9dd87/attachment.html>