[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction
Martin P Pain
martinpain at uk.ibm.com
Wed Jul 31 09:35:49 EDT 2013
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 <fiedler at us.ibm.com>
To: oslc-automation at open-services.net,
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"
<oslc-automation-bounces at open-services.net>
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
_______________________________________________
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/20130731/1bd894e9/attachment-0001.html>
More information about the Oslc-Automation
mailing list