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: [email protected]
Find me on: and within IBM on:
Embassy Golf Links Business Park, Block B
Bangalore, Karnataka 560071
India
From: David N Brauneis <[email protected]>
To: Martin P Pain <[email protected]>,
Cc: [email protected], Oslc-Automation
<[email protected]>
Date: 03/25/2013 05:17 PM
Subject: Re: [Oslc-Automation] Complex automation tear down
scenario for discussion
Sent by: "Oslc-Automation"
<[email protected]>
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: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874
From: Martin P Pain <[email protected]>
To: [email protected],
Date: 03/25/2013 07:06 AM
Subject: Re: [Oslc-Automation] Complex automation tear down
scenario for discussion
Sent by: "Oslc-Automation"
<[email protected]>
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 <[email protected]>
To: Michael F Fiedler <[email protected]>
Cc: [email protected], Oslc-Automation
<[email protected]>
Subject: Re: [Oslc-Automation] Complex automation tear down scenario
for discussion
Message-ID:
<of589b2e48.efa83f75-on85257b35.006d8234-85257b35.006eb...@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: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874
From: Michael F Fiedler/Durham/IBM@IBMUS
To: [email protected],
Date: 03/21/2013 12:32 PM
Subject: [Oslc-Automation] Complex automation tear down scenario
for discussion
Sent by: "Oslc-Automation"
<[email protected]>
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
[email protected]
919-254-4170_______________________________________________
Oslc-Automation mailing list
[email protected]
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
[email protected]
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
_______________________________________________
Oslc-Automation mailing list
[email protected]
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
