[Oslc-Automation] Complex automation tear down scenario for discussion

Thu Apr 4 08:19:28 EDT 2013

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/48fbde62/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/48fbde62/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/48fbde62/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/48fbde62/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/48fbde62/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/48fbde62/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/48fbde62/attachment.gif>