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
