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 <[email protected]> To: Stephen Rowles/UK/IBM@IBMGB, Cc: [email protected] Date: 22/05/2013 16:40 Subject: Re: [Oslc-Automation] Thoughts on teardown scenarios Sent by: "Oslc-Automation" <[email protected]> "Oslc-Automation" <[email protected]> wrote on 05/22/2013 02:52:44 AM: > From: Stephen Rowles <[email protected]> > > 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 [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
