[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-0003.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.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.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-0001.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-0002.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-0003.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.gif>


More information about the Oslc-Automation mailing list