[Oslc-Automation] Thoughts on teardown scenarios

Wed May 22 03:52:44 EDT 2013

Charles,

I can see where you are coming from with the idea that an Automation Plan 
is more of an instruction that a representation of something real, but I 
don't agree :).

I don't see why Automation resources are (or should be) any different from 
the other resources defined in OSLC. When you look at, for example, 
Quality Management, the spec don't expect a Test Script to simply be a 
pointer to another sort of resource that really contains the information 
needed, it is a representation of that information.

I think that Automation resources should be the same, they should be 
representing the information directly not being a pointer to yet another 
resource. I think this is more in keeping with the way other OSLC 
resources are defined. If you look at the language as defined in the spec:

Automation Plan - Defines the unit of automation which is available for 
execution. 
Test Script Resource - Defines a program or list of steps used to conduct 
a test 

The definition of both of these resources doesn't give any indication that 
they are simple pointers to something else (at least to my reading).

Taking the VM example that you defined I can see that having many 
Automation plans is nice because there is little understanding required 
about each one. However what if the running instance of the VM is 
something created many times a day, the number of Automation Plans will 
rapidly get large, consider a VM template that is turned into a real VM 20 
times a day (not unreasonable if you have a large scale dynamic 
provisioning system).

If there needs to be 3 automation plans for each instance for 
restart/start/stop that's 60 automation plans every day, this rapidly will 
get out of hand. There are also other more dynamic types of automation 
that are likely to occur more frequently than 20 times a day, for large 
scale build and automated test systems I could easily envisage some form 
of automation execution occurring 100's of times a day.

I think that having system where each automation execution requires both 
an automation result, a.n.other OSLC object that that result points to, 
and then 3 (or more) plans to perform actions such as start/stop will 
cause scalability issues for any frequent execution automation provider.

Stephen Rowles

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

From:   Charles Rankin <rankinc at us.ibm.com>
To:     oslc-automation at open-services.net, 
Date:   21/05/2013 18:34
Subject:        [Oslc-Automation] Thoughts on teardown scenarios
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>

This ended up being longer than I thought.  Apologies up front. 

Let me start by saying that I think the teardown scenarios have a lot of 
value, and are something that we want to make sure that the OSLC 
Automation spec supports.  My biggest concern over the current proposals 
for supporting these scenarios is the use of Automation Plans / Results as 
surrogates for the deployed environments.  As I view it, an Automation 
Plan is nothing more than the definition of some action (or set of 
actions, either explicitly or implicitly defined) that a provider can 
execute.  An Automation Request is the indication that a desired action 
should be taken (along with any necessary data needed to successfully take 
that action).  And, an Automation Result is the "history" of what happened 
when that action was taken. This, to me, is very opaque, in a good way. 
Many many different things could have occurred as part of the action being 
taken -- a build could have been generated, a software stack/topology 
could have been instantiated, a car could have been fabricated, a valve 
opened, etc.  I think we should tread carefully before adding data 
specific to one of these contexts to the core of the specification.  The 
notion of "profiles" came up as well as the idea of people building 
"domain" specs on top of Automation.  Both of those sound like plausible 
and valuable ideas to me. 

Turning specifically to the teardown scenarios.  When I think about this, 
I envision two predominant camps of providers.  Those that are effectively 
generic with no idea what their actions are doing, and those that are 
purpose built which have an explicit understanding of what they are being 
asked to do.  In the generic case, I don't see any really viable way for 
this to be handled without conscious intent by the users of the provider 
in creating appropriate automation teardown plans (possibly dynamically) 
to complement those that were created to instantiate the environment.  So, 
in the generic case, the coupling of multiple automation plans into a 
cohesive group is user-defined.  For the purpose-built case, my 
expectation is there is a "resource" that exists that the provider knows 
it can take a specific set of actions on (possibly with the ability to 
have that set extended by the user).  As a simple example, let's think of 
a system for managing Virtual Machines.  The VM is the resource here, and 
the system likely knows how to instantiate one, (re)start/stop it, and 
delete it.   Technically, there are probably two resources, the VM image 
and the live VM instance.  You'd take the instantiation action on the 
image and the (re)start/stop and delete actions on the instance.  That 
distinction will actually come in handy in a moment. 

Keeping with the VM example.  I would expect that the provider would 
expose the VM image as a resource of some kind (but not as an Automation 
Plan itself).  In that resource there would be a link to the instantiate 
action (i.e., the Automation Plan that knows how to instantiate an 
instance of that image).  A consumer could submit an Automation Request 
for that Automation Plan.  The Automation Result generated from that, 
amongst other things, would have a link (probably through a Contribution) 
to the resultant VM instance (which is, again, some other type of 
resource, but not an Automation Result itself).  That instance would have 
links to various actions (Automation Plans) that could be taken on it 
(e.g., the (re)start/stop and delete mentioned above).  Note, the 
"provider" I mentioned at the top of this paragraph is really two (or 
more) providers.  One for the VM resources (and whatever domain/spec they 
belong to) and one for the Automation spec. 

In the generic provider scenario, I would envision that further actions 
that could be taken as a result of the completion of one Automation Plan 
would show up as contributions on the first.  Those contributions may be 
dynamically generated by the first automation plan itself, or generated by 
the provider due to (user-defined) metadata associated with the Automation 
Plan.  It seems like it could be useful for us to define this type of 
contribution explicitly (mostly just an action name/type and a link to the 
appropriate Automation Plan). 

I think the whole discussion around registering "interest" (or 
dependencies) is also very useful.  However, I don't see that as 
Automation specific.  I think that is something that better belongs at 
Core or a separate spec.  Perhaps we do some work to scope and spec out 
something initially and bring it forward?  This is similar to how we would 
handle the idea of Notifications that came up during the v2 spec work 
around Automation. 

If you made it this far, kudos!  I'll be out of the office for a while (a 
solid two weeks), but I'll be tracking responses and reply when I get 
back. 

Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386_______________________________________________
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/20130522/b0d9709f/attachment-0003.html>