[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction
John Arwe
johnarwe at us.ibm.com
Wed Aug 21 09:36:38 EDT 2013
> 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 <stephen.rowles at uk.ibm.com>
To: oslc-automation at open-services.net,
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"
<oslc-automation-bounces at open-services.net>
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
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130821/48cdf970/attachment-0003.html>
More information about the Oslc-Automation
mailing list