[Oslc-Automation] Complex automation tear down scenario for discussion
Martin P Pain
martinpain at uk.ibm.com
Thu Apr 4 09:50:09 EDT 2013
Yes, I believe the orchestrator that holds the master plan will know the
correct teardown process for all the component deployed resources.
However, the problem comes when another client registers that it is using
one of those component auto results that the master plan set up.
So the scenario goes something like this:
* Client A asks provider 1 (the orchestrator) to deploy the master plan.
* Provider 1 (the orchestrator) wants to start auto plan A on provider 2,
but that has a dependency on auto plan B on provider 3
* (the fact that auto plan B is used to fulfil this dependency is most
likely controlled by the orchestrator, and may be represented in auto
plan A as in the Automation plan configuration data scenario or may
not be represented there at all and may be the result of manual
configuration in the master plan).
* The orchestrator asks provider 3 to start auto plan B, which results in
the creation of auto result B.
* When that has completed, the orchestrator asks provider 2 to start auto
plan A, which results in the creation of auto result A.
* The orchestrator somehow marks that auto result A dependsOn auto
result B. (Exactly how this happens can be discussed.)
* The orchestrator may or may not have needed to pass in information
from auto result B, depending on the nature of the dependency.
* Another client, client B, sees auto result A and registers itself as
a user of that result.
* Some time later:
Client A indicates to the orchestrator that it is finished with the
master plans result, so it can be torn down.
* The orchestrator performs its tear down procedure, with the following
results:
* Auto result A (the main component, which depends on auto result B, and
which client B is using) should not get torn down until client B has
indicated that it is finished (i.e. deregistered its interest)
* Auto result B (the dependency) should not get torn down until auto
result A has been torn down (i.e. has finished it) because of the
dependsOn relationship form auto result A.
I've left the last few points abstract as the what the required result is,
rather than how this would be achieved, as there are multiple ways in
which this could be done. It is not necessarily the orchestrator who has
the responsibility of achieving the behaviour stated, but it may be - this
will come out o the discussion of how it is achieved.
One particular thing to consider is mixes of OSLC automation spec versions
implemented by the different clients and providers (although anyone using
or providing tear down must be using v3) and also if areas of the spec
(like supporting or consuming multi-use, or supporting or querying the
dependsOn property) are optional, then can this scenario still work with
certain providers unaware of those behaviours? (e.g. it would be
preferable if any providers could be used by an orchestrator, even if they
do not support dependency mapping - although I'm not sure if this is
possible. Hopefully all providers would support tear-down if it makes
sense in their product's area.)
I'm aware this scenario is not in the easiest form to read (too many "A"s
and "B"s), but I've tried to get it together quickly before today's
meeting to demonstrate why the automation spec might address dependency
mapping in the context of tear down.
Martin
From: Rohit Shetty <rohit.shetty at in.ibm.com>
To: David N Brauneis <brauneis at us.ibm.com>,
Cc: Martin P Pain/UK/IBM at IBMGB, oslc-automation at open-services.net,
Oslc-Automation <oslc-automation-bounces at open-services.net>
Date: 04/04/2013 13:20
Subject: Re: [Oslc-Automation] Complex automation tear down
scenario for discussion
David/Martin,
From the initial note that Mike sent in this thread, it looks like
the "Master" plan that invokes/orchestrates other plans seems to know
which plans to execute and the sequence to follow without any of the
dependencies or relationships defined. If there is "magic" there, why
should tear down be any different? I would think there is a "Master" plan
that knows how to tear down the environment by invoking sub-plans and
verifying/validating the tear down of sub-environments.
Now if that's not the case and if we are looking at modelling the
relationships:
- Would the relationships be modelled between the plans or the results or
both?
- How do you communicate status of dependent activities/plans?
- How does a parent plan know that a dependent plan has already
been executed?
- How does the plan know that a dependent plan that was invoked
completed successfully? Who is responsible for tracking the status?
Regards,
Rohit Shetty
Architect - Manageability Integration, IBM Master Inventor
Tivoli, Software Group, IBM
Phone: 91-80-41055478 | Mobile: 91-98866-26248
E-mail: rohit.shetty at in.ibm.com
Find me on: and within IBM on:
Embassy Golf Links Business Park, Block B
Bangalore, Karnataka 560071
India
From: David N Brauneis <brauneis at us.ibm.com>
To: Martin P Pain <martinpain at uk.ibm.com>,
Cc: oslc-automation at open-services.net, Oslc-Automation
<oslc-automation-bounces at open-services.net>
Date: 03/25/2013 05:17 PM
Subject: Re: [Oslc-Automation] Complex automation tear down
scenario for discussion
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
Martin,
I like where you are going but as we move more into automated deployments
and automated testing, there are going to be cases where things like the
database (or messaging) could be handled via service virtualization... Do
we think how you are proposing will handle these scenarios? I'm not
suggesting that it will not but just want to ensure that we are thinking
about those scenarios.
Regards,
David
____________________________________________________________________
David Brauneis
STSM, Rational Software CTO Office, Advanced Technology & New Product
Incubation
email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
From: Martin P Pain <martinpain at uk.ibm.com>
To: oslc-automation at open-services.net,
Date: 03/25/2013 07:06 AM
Subject: Re: [Oslc-Automation] Complex automation tear down
scenario for discussion
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
I wonder if it would be useful to model this with a "dependsOn" property.
(I expect other workgroup/s have a similar property that we could learn
from and/or use.) That way if the auto result for the deployment of the
enterprise web app and the auto result for the startup of the database
server are controlled by different providers, then the master request (or
the enterprise web app request, if it is happy to consume auto requests
rather than generic environment configuration data) can model that
dependency, so the DB server provider can know not to tear it down until
the we app has finished.
This dependency mapping would be in effect another form of "interested
party" as mentioned in the "temporary deployment scenarios".
The direction of the link could be discussed. If it's from the dependant
resource (web app) to the dependency (DB server), then there has to be
some way for the dependency (DB server) provider to know about it - but
I'm sure there are ways to achieve this - and this seems the most natural
direction to map it as the dependant resource knows about its
dependencies.
On the other hand, mapping it the other way would be simpler to check for
other resources dependant on any given resource, but would require all
providers that support that mapping to allow any other providers to add
that property. This direction does seem much simpler to me.
We could perhaps also do something to mark when that relationship has the
"sub-optimisation" that David mentioned - the web app could say that not
only is it dependant on the web app server, but that tearing down the
server would achieve a complete tear down of the web app (but only if
that's true - it wouldn't always be if other cleanup is required). (The
concepts of composition/aggregation might be applicable here.) Although
what the exact interaction between the different providers would be I'm
not sure.
My comments in summary: we could model dependencies between deployed
resources (auto results), which is related to the "interested parties"
concept but specific to system dependencies. These relationships could
also be flagged to allow optimisation.
Martin
Date: Thu, 21 Mar 2013 16:09:12 -0400
From: David N Brauneis <brauneis at us.ibm.com>
To: Michael F Fiedler <fiedler at us.ibm.com>
Cc: oslc-automation at open-services.net, Oslc-Automation
<oslc-automation-bounces at open-services.net>
Subject: Re: [Oslc-Automation] Complex automation tear down scenario
for discussion
Message-ID:
<OF589B2E48.EFA83F75-ON85257B35.006D8234-85257B35.006EB4C0 at us.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Michael,
I think the search criteria to determine if anyone is registered as
interested in them is just as you indicate, recursive starting with the
final piece and working back to the initial piece. I think there is
possibly a sub-optimization in you example where if no one is registered
as interested in the application server or database server, then rather
than uninstalling the applications and database tables, then
uninstalling/de-provisioning the application server and database it can
all be accomplished by removing the application server and database
server.
Regards,
David
____________________________________________________________________
David Brauneis
STSM, Rational Software CTO Office, Advanced Technology & New Product
Incubation
email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
From: Michael F Fiedler/Durham/IBM at IBMUS
To: oslc-automation at open-services.net,
Date: 03/21/2013 12:32 PM
Subject: [Oslc-Automation] Complex automation tear down scenario
for discussion
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
In today's OSLC Automation workgroup there was some interesting discussion
around deployment environments created by the execution of multiple
automation plans orchestrated by a top-level/"master" plan. When a
consumer is finished with the environment it can request tear down, but
what are the implications for the "sub-environments"? We discussed an SAP
landscape, but I think a generic enterprise application illustrates the
issue as well:
- consumer requests deployment of the enterprise application environment
via a top-level automation plan. The top-level plan in turn runs
automation plans to:
- provision a virtual network
- install and deploy a DB server
- install and deploy an application server
- install and configure an enterprise application and its DB
What is the correct behavior when the consumer indicates the environment
is no longer required? Recursive tear down of any environments which have
no one registered as interested in them?
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170_______________________________________________
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/20130404/d4411180/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1588 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/d4411180/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/d4411180/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 470 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/d4411180/attachment-0005.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 467 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/d4411180/attachment-0006.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 494 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/d4411180/attachment-0007.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2404 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/d4411180/attachment-0001.gif>
More information about the Oslc-Automation
mailing list