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

[John Arwe]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130820/35489d7d/attachment-0003.html>