[Oslc-Automation] Automation Template Scenarios

[John Arwe]

Martin, I don't think you're missing any Automation discussion.  Those of 
us directly involved with the product in question did have reasonably 
complete discussions, as you might imagine.  I'll try and catch the list 
up some with those (now that the product is available, some of the 
non-technical hurdles go away).

I parse the problem into a couple of parts.

1: Automation 2.0 did something non-standard (in the sense of "unusual 
with respect to prevailing usage patterns") when it coupled creation of a 
resource with execution of an action ... an action BTW that results in a 
second resource coming into being, although I certainly grant that if they 
have the same URL it's only 1 resource but has 2 types.  However, we were 
intentionally treating the multityping case as an option not a 
requirement.  I was there, I didn't see this except in hindsight, so bad 
me (but at least I had company ;-) ).

2: Core 2.0 provides no way for a client to introspect pre-fill support on 
a creation factory, yet the interaction pattern in question is completely 
dependent (semantically) on the "template" being used.  So any 
implementation in this situation is dependent upon tight coupling 
(non-standard out of band information) to know about pre-fill support. Our 
product doesn't want to be tightly coupled; defeats the purpose.  Clear 
omission in Core 2.


One way to assess the complexity of a solution is "how much new spec work 
is required?", and this is to some degree bound to "...and where would 
that work occur?".  The first is a proxy for adoption complexity (what new 
concepts/implementations do clients need to worry about), the second is a 
function of how generally reusable are the problems/solutions.

Had Automation 2.0 originally addressed its "create + run" requirement by 
explicitly _adding to_ the standard interaction pattern, so the "run" 
implication was simply an Automation-defined extension on a standard 
create request (essentially setting the initial state to "runnable" rather 
than requiring a subsequent PUT/PATCH to do so, a perfectly valid 
optimization), we would not be here.  We'd fix this in Core by making the 
pre-fill support explicitly introspectable and be done with it... we might 
have even done that for Automation only first (but I suspect the WG leads 
would have realized it's a general Core problem and fixed it there, as we 
did with allowing usage on Services).

So to net that out: two new terms (one in Automation, one in Core) and 
you're done.  Existing/new clients that wanted to know about pre-fill 
support for other reasons get a general solution to their general problem, 
existing clients that don't care don't change at all.  Automation clients 
(the ones that want this "create-runnable" binding vs not) have to do a 
bit more work.  Since none of the other existing domains have asserted a 
need to do templates, keeping the solution Automation-specific for now is 
not obviously crazy talk.  If they were to arise, we might decide that the 
solution is better placed in Core.  I did ask during our internal 
discussions if anyone involved saw a strong potential for re-using it 
elsewhere, no one did.  It's completely fine to repeat discussion that in 
Automation with a wider audience, like you.  Providers didn't exactly jump 
at the prospect of persisting the created "templates" on the grounds that 
they'd have no way to know when to delete them (i.e. fears of "memory" 
leaks); once I pointed out that they could be garbage collected, and that 
in fact this is no different than a robust server would need to do for any 
other resource it manages, those fears died down.

The original proposal added templateDialogs, with a new behavior on the 
delegated dialog interface.  That is clearly, from a run-time perspective, 
more efficient and optimized.  It's also more new concepts for an 
implementer to learn, and more to decide whether or not to support.  The 
same question about function placement occurs.  If this were added to 
Core, then it ups the consumption complexity of every domain (not just 
Automation); if left in Automation, we face the distasteful prospect of 
moving it later since we eschew "hard" cross-domain spec dependencies 
should a similar need arise elsewhere (which is completely different than 
vocabulary reuse, to be clear... stable vocabulary reuse is A Good Thing 
regardless of the vocabulary's source).  An added question at the spec 
level is whether or not a change of this magnitude could be done in Core 
2.0; to me that answer is no (too big, and we've been talking about 
drafting 3.0 for months, and now LDP is getting mature enough that 3.0 is 
going to become real).  If it can't be done in Core 2, are we willing to 
tie Automation.next to Core 3.0 which could be a year away? 
The template function was needed by June (last month), so an obvious "no" 
in their eyes.  With the simpler version, fixing 2: seems absolutely 
doable in Core 2 (just like we did with usage) and as you point out we can 
use a custom state for the moment to get us the rest of the way on 1:. 
Product schedule was a forcing function.

I agree these are not mutually exclusive, too.  We have to be sure, if we 
do both, that it's worth the adopter complexity.  Any time there is >1 way 
to accomplish the same thing, people naturally ask "how do I know which is 
right [better for my case]".  If we punt on the answer, as we 'often' do, 
too much choice is worse for them.

For our products, using the more-KISS but less optimized approach was 
deemed good-enough (the template-creation flow is rare compared to making 
requests that use the template), so once they got to that point it became 
a question of "so who's going to invest the time to spec out the 
templateDialog, the delegated dialog flow, implement it several times 
(necessary to put it anywhere), and make the argument for inclusion in 
Core 2?"  Response: crickets chirping.

>  This would allow the consumer to create a template and save it itself 
(not on the provider); ...(both of these put the consumer in control)
Both options accomplish this.  The difference is whether or not the 
provider has any obligation to persist what was created and if so how the 
rest of its lifecycle is managed.
Creation => persistence has been a standard responsibility since before 
OSLC's days, in most circles.  Atom normalized this in REST circles. 
That doesn't mean we Must re-use that pattern in this case, but we should 
be aware when we are consciously trying to define new patterns vs re-use 
widely used existing ones, and the implication of that choice on adoption. 
 Implementers adopt as a means to an end, not as the end.  If the means it 
more painful than the end, not much adoption.

> or to create a resource in "don't execute yet" state on the provider and 
then change that state when it's ready (both of these put the consumer in 
control); 
This option actually fails to accomplish the desired result, because it is 
only useful for a single execution.  What the schedulers want to do is 
create a "template" once and then re-use it multiple times.
You might think of it as creating a consumer-scoped Automation Plan.
Thinking about it this way does make me wonder who _should_ be persisting 
them.  Products playing a role analogous to provider don't persist the 
"templates" today, but maybe they should.  I can see both sides of the 
issue.

> or for the provider to expose the scheduling settings in the creation 
dialog and control the "don't execute yet" state on its own (this is where 
the provider's in control - and is possible in v2, ...
Consumers (several of ours at least) will deal with multiple providers 
when creating templates, so they show a list of potential providers to the 
user for selection.  They need proactive introspection so they can weed 
out "Automation 2.0 but not template-capable" providers from that 
selection list, as users expect.


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/20130712/cbc05d0b/attachment-0003.html>