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
