[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction

[Stephen Rowles]

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 <johnarwe at us.ibm.com>
To:     oslc-automation at open-services.net, 
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" 
<oslc-automation-bounces at open-services.net>



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
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/20130821/e805b868/attachment-0003.html>