[Oslc-Automation] Thoughts on teardown scenarios

[Martin P Pain]

Hi Charles,

You said:
"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"
"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."
"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."

Taking this word-for-word, this seems to be like it would require 
consumers to know how to use the "contributions on the first [Automation 
Result]" in combination with the "URL to the VM Instance resource upon 
which to act". In other words, it needs to know (in some way, either from 
the data or the spec) which input parameter (if there are many) the 
resource-on-which-to-act should be passed in as.
One possible approach (which may be what you were already thinking) is 
that you could add that resource's URL as a query parameter on the 
Automation Plan's URL, so the contribution's rdf:reference contains all 
the information that is needed to execute the action against this 
resource. (Of course to the consumer it would appear to be a different 
Automation Plan, as it has a different URI, but the provider can produce 
these on-the-fly as the same as the basic plan but with a default value 
for the input parameter, or similar.)

There is a second issue, at least for the purpose-built provider, in 
finding the automation plans. Teardown is something that might in many 
cases be important to perform when the deployed resource is finished with, 
e.g. for VM images on a public pay-per-minute/-per-CPU-cycle cloud. As 
such consumers need to know how to find these actions without knowing the 
details of how the provider represents its resources. We could define that 
they should look for a defined property (e.g. 
oslc_auto:exposesAutomationPlan) on the target of all 
oslc_auto:contribution references. But then what if a provider represents 
an important action as being on a resource that is referred to by a 
contribution, rather than that resource being a contribution itself?
e.g.
?AutoResult oslc_auto:contribution ?a
?a ?_ ?b
?b oslc:auto:exposesAutomationPlan ?c
Where ?b might be another Automation Result (if this one's plan is a 
composite plan), or perhaps there's just a very complex graph of what was 
contributed.

While I'm sure that it would be useful to have a property for any 
arbitrary resource to use to refer to Automation Plan that represent 
actions on itself, reliably finding these actions once you leave the 
Automation Result seems to be hard to ensure.

Perhaps a way around to this would be to say that any critical actions 
(such as teardown) should be contributions on the result in their own 
right (even if they are also exposed on other contributions, or elsewhere 
in the graph). That way if consumers understand the representation of the 
contributions they can navigate around it (or allow the user to do so) and 
provide the actions on the viewed resources to the user, but if they don't 
then they at least have the most important ones at their fingertips, 
referred to directly from the Automation Result.
Or we could just define that a consumer can be reasonably be expected to 
check the contributions for: either being an Automation Plan themselves, 
or containing a link of the defined type (e.g. 
oslc_auto:exposesAutomationPlan if we wanted to call it that).

So those issues are:
How do we make sure the consumer can take a reference to a parameterised 
Automation Plan and make sure it is executed on the right resource 
(preferably for as many consumers as possible - i.e. putting least burden 
on the consumer implementations)?
How do consumers find those references in the first place? What 
expectations can the consumers have about where the providers will place 
those references? (Again, preferably reducing the burden on the consumers 
for greater interoperability.)

Martin



From:   Charles Rankin <rankinc at us.ibm.com>
To:     Stephen Rowles/UK/IBM at IBMGB, 
Cc:     oslc-automation at open-services.net
Date:   22/05/2013 16:40
Subject:        Re: [Oslc-Automation] Thoughts on teardown scenarios
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



"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_______________________________________________
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/20130523/f7503f64/attachment-0003.html>