[Oslc-Automation] Thoughts on teardown scenarios

[Charles Rankin]

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
05/22/2013 02:52:44 AM:

> From: Stephen Rowles <stephen.rowles at uk.ibm.com>
> 
> 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.

I agree that an Automation resource should represent its resource 
directly, and I think the description I provided is in line with that.

> 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). 

My feeling is that the Automation Plan is a definition of the *action* 
that is to be taken, not of the resource on which the action is to be 
taken.  Typical OSLC resources describe some form of "object" (give me a 
touch of latitude here for the sake of an upcoming analogy).  And OSLC 
describes mechanisms to do basic CRUD (Create/Read/Update/Delete) 
operations on them (in OO parlance, OSLC would provide new/delete and 
getter/setter methods).  My view is that the OSLC Automation spec provides 
a means to define arbitrary "functions" or "methods" for OSLC "objects" 
(or "actions" on "resources" if you prefer).

In the v2 version of the spec, I think we basically worked through the 
mechanics of how to execute/invoke actions in a standardized way.  Now, as 
we look to the v3 version of the spec, we are really starting to 
understand how to apply that mechanism to various tasks and/or domains. 

> 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.

In the generic provider scenario, I think there are exactly 3 plans here, 
one for each of restart/start/stop.  One of the parameters into the plan 
would be the URL to the VM Instance resource upon which to act.  Thus, it 
doesn't actually scale out based on the number of VM Instances.  For the 
purpose built provider, I could easily see the same mechanism being used, 
meaning the references to the restart/start/stop plans on the VM Instance 
are pointing to the "generic" versions, and you still pass the VM Instance 
URL as one of the parameters.  And, if it's truly purpose built, then the 
plans are likely to not exist as real resources, but rather OSLC 
Automation facades to existing functionality.  So, the definitions are 
just generated (or responded to) on the fly.

As an aside, if you take the viewpoint that the Plan/Result *is* the 
resource, I don't understand how you would otherwise account for these 
different actions.  You would invoke the Automation Plan (which would, I 
think, represent the VM Image) for instantiating the VM Instance, with, I 
presume, the Automation Result representing the actual VM Instance.  And, 
I get (I think) that the VM Instance would get deleted when the Automation 
Result goes away.  But, how do I restart/start/stop the instance in this 
scenario? 

Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130522/9071a60b/attachment-0003.html>