> I've heard it said on numerous occasions by various people on the calls that the Automation spec is about actions to create other things.
Usually "what X is about" statements are shaped by how people are [thinking about] using it, which is in turn based on their experiences. (Good) specifications typically try to do just what's in scope, and otherwise stay out of the way.... thus they admit several (ideally: many) uses, perhaps even apparently conflicting ones, and certainly ones that the promulgators never imagined. The obvious question to a statement like "the Automation spec is about actions to create other things", in the context of OSLC which tries to color within the lines of REST and Linked Data, is "should we then deprecate POST for create?" ... and FWIW at the HTTP level in W3C's LDP WG, lots of people still want to allow other ways to create resources, like PUT and even PATCH. I don't think anyone has actually advocated dumping POST or CreationCapabilities -- just an example of reductio ad absurdum. We have to ask what the limits are. More generally, any HTTP operation can be encapsulated (via Automation, or some other spec) ... but I don't think many would say we want to dump REST and do everything via Automation. If you have both, and the capabilities of one include the other, you have to establish some community guidance, rules, norms, whatever for when to use each. I think we're starting to feel our way through that process now. For my money, what Automation adds that the HTTP community has no standard answer for is how to handle long-running requests without relying on a persistent connection. Otherwise, POST would be all you need; the Automation vocabulary is a useful refinement of POST, but parameter passing via name-value pairs and having no standard Plan URIs are not substantively different than naked POSTs. But monitoring, canceling, some standardization of current/final states ... clear net positive, and very general, for those long-running interactions. The question coming up from some areas like our Provisioning and Scheduling products is really how to expose what they manage HTTP-RESTfully *and* allow those same operations to be "automated" (scheduled), whether they turn out to be long-running or not, without implementing "many" specs. > So given that I think the Automation spec is all about being a command pattern, it doesn't seem unreasonable to have 2 different commands (2 Plans) which affect the system in different ways. Or do people not expect the Automation Spec to be used this way? I would welcome some documented clarity around this. IMO: Automation allows you to have as many Plans as you like, implementing whatever operations you like (including each HTTP operation, if the mood strikes you). Regardless of which design pattern(s) you think it fits. If you want to define more constrained (yet still general) operations like Start/Stop, than HTTP gives you (or is likely to) then you end up with vocabulary(ies) for those ... both Actions and AutoPlans can fit that bill; the net difference between the two so far is that if the provider uses AutoPlans, then the client interaction style is assumed to be aligned with long-running requests (fair disclosure: I did convince people in Automation 2.0 to allow short-running requests as well via the 200 flow, but general clients still must be prepared for the others). If the provider sticks with straight HTTP, or Actions, the client interaction style is assumed to be aligned with short-running requests; HTTP provides 202 for long-running, but leaves completely open what the "monitor resource" looks like and how the client interacts with it after the 202 is received. > To comment on the idea of HTTP delete on the manufactured resource; I don't like that idea because we are straying into someone elses specification to define behaviour we require for Automation. The created resources may be completely custom and outside of OSLC's remit and I don't think we should be forcing them to support DELETE in that way to get our desired behaviour. I think that's our choice; i.e. I understand the issue, and it seems trivial in my head to spec it without that problem. But I'm not married to either alternative at the moment myself. > With the current RQM to RTVS integration the automated "stop" step is not possible and relies on user interaction. At least in the short term this is the major pain point that I would want to address. RQM should be able to "stop" what it started, and it needs to be able to do that in a way that is not RTVS specific so that other automation providers could be used. I heard no objections to doing so last week, even via the proposed predicate. If that were to turn out to be a "tactical" solution in the long run, with something like Actions being the eventual "strategic" one, fine ... this is linked data, it can be exposed both ways once the long term one settles out. The discussion on the teardown predicate was only around where it's exposed, the Plan vs the Result. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario From: Stephen Rowles <[email protected]> To: [email protected], Date: 08/21/2013 05:07 AM Subject: Re: [Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction Sent by: "Oslc-Automation" <[email protected]> John, To pick up on your OO analogy. If that is correct then I would agree it seems odd. However I've heard it said on numerous occasions by various people on the calls that the Automation spec is about actions to create other things. Given this I'm not sure your constructor analogy holds true. >From what I've understood people expect the Automation Plan/Request/Result to be more analogous to an OO "Command" pattern than an object construction pattern. In the command pattern various command objects exists which do things, you create a command to achieve what you want to do which are then executed as/when appropriate to cause the desired effect. So given that I think the Automation spec is all about being a command pattern, it doesn't seem unreasonable to have 2 different commands (2 Plans) which affect the system in different ways. Or do people not expect the Automation Spec to be used this way? I would welcome some documented clarity around this. To comment on the idea of HTTP delete on the manufactured resource; I don't like that idea because we are straying into someone elses specification to define behaviour we require for Automation. The created resources may be completely custom and outside of OSLC's remit and I don't think we should be forcing them to support DELETE in that way to get our desired behaviour. With the current RQM to RTVS integration the automated "stop" step is not possible and relies on user interaction. At least in the short term this is the major pain point that I would want to address. RQM should be able to "stop" what it started, and it needs to be able to do that in a way that is not RTVS specific so that other automation providers could be used. So in Summary: 1) Is it correct that the Automation spec is intended to be a Command pattern style spec as I've described? 2) Do people agree that we shouldn't be placing requirements on implementation details outside of the Automation spec? Stephen Rowles From: John Arwe <[email protected]> To: [email protected], Date: 20/08/2013 19:35 Subject: Re: [Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction Sent by: "Oslc-Automation" <[email protected]> Catching up with this finally. There's a persistent underlying assumption that (REST hat on) feels misplaced, i.e. that the deploy Plan-A links to a teardown Plan-B, and Plan-B has a parameter (ick!) telling it what to teardown (which sounds a lot like destroy). The equivalent OO statement is that I call a class's constructor (Plan-A) to manufacture an instance, and then I call some other class entirely (Plan-B) to destroy the instance. [brows furrow] You will see a version of this point in the 8/15 minutes now that I fleshed out some things Michael was unable to minute. The deployed environment (virtual service) created as a result of creating an Automation Request (i.e. a constructor call, with parameters) against Plan A is the thing you want to tear down as I understand it, not all instances of Plan A output. The 1:1 corresponding, already existing, Automation resource is the Automation Result. So it seems perfectly natural that the Result (perhaps indirectly, via the "deployed env" it created) would tell a client how to tear it down. I see no way the *Plan* can do so, because the *Plan* lacks knowledge of whatever parameters accompanied the Request (and in practical terms, any output parameters, which might also come into play in the general case). The context needed to reverse the process is the original request; that has to be accessible to the teardown implementation somehow. Smart implementations might need less than the full original request. Since everything needed is accessible to the implementation, there is no need for (client-specified) parameters on teardown (goes my argument); if you want to take some -different- action, like "preserve env for later debug by humans", that's a -different action- with a different link. I do think there is room for debate on where that link gets placed, on the Result or on the "primary resulting resource", depending upon what semantics you attach to each. On the Result: you're depending on the Result to live on as long as the deployed environment. Not clear that you need to introduce that dependency. On the "manufactured resource", linked to by the Result: Not clear to me that you need anything more than the link and HTTP DELETE on the "manufactured resource" to trigger teardown. Note that in both cases, implementations CAN use a "Plan-B with RPC-ish parameter" style by putting the parameter in the URI, if they so desire. Other implementations just have to ensure that whatever resource holds the teardown link has whatever subset of the Request parameters it needs to function properly. That all seems like tasty loosely coupled goodness. As to the worries about the "right" cardinality of the proposed auto:produces/d predicate(s), containers is the obvious fix. The cardinality is 0:1, if your Request produces >1 thing then its output is a container of those things. fin. For those who cry out "aha, but 'teardown' might just be deregistration of 'interest' so the env is eligible for re-use, so DELETE goes too far", I say this is all tied up in the semantics of the manufactured resource (which Automation leaves open). If the manufactured entity is just an "interest registration", then deleting it is exactly what the client wants. If it is "the env", ditto. It's all Automation provider implementation detail; if the provider wants to allow clients to see through the encapsulation, that's called a proprietary extension. > There's no way for the orchestrator to know that the two plans are linked in this way To be clear: I agree with this, modulo the "plan/Result/env" substitution above. I.e. I do see a reasonable requirement for an "undo a previous Auto Request" 'action'. > "it can find the reference in the result contributions to the deployed environment" vs mult contributions Ditto, modulo the "where to place the link" discussion above. If the inversion/teardown link is always on the Result, it's not obvious to me that we need produced/s. It would be useful to be clear on each one why it's needed (exactly what fails without it), and if there are dependency relationships between the decisions then understand those. > a means to determine which input parameter that resource should be passed in So far, I've argued there is no parameter for teardown so this is moot. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario _______________________________________________ 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 _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
