[Oslc-Automation] Oslc-Automation Digest, Vol 8, Issue 4

[Charles Rankin]

oslc-automation-bounces at open-services.net wrote on 10/13/2011 02:13:27 AM:

> Pramod K Chandoria <pchandor at in.ibm.com>
>
> Broadly speaking, proposed scenario does not go out of synch with 
> what we have been talking about the AutomationPlan, Automation 
> Request and Automation Result. 
> It just fits into the right position and answers "How to get 
> Automation Result from AutomationPlan". 
> It does not introduce any new resources here. Although if consider 
> Tool Registeration step(fist step of the scenario) to be 
> standardized, it might define another resource say "AutomationTool". 

I'm not sure I'm using the right words here, but this scenario feels more 
like we are standardizing how to create automation providers than how to 
standardize the way automation providers integrate with the rest of the 
world.  I postulate that most consumers of this spec are looking to 
understand what work (i.e., the AutomationPlan) can be done by an 
automation provider, how to invoke it (likely via the AutomationRequest 
mechanism), and what the results are (i.e., the AutomationResult).  At 
present (and I believe it is important to realize this is a point-in-time 
statement) I don't believe they are looking for a standardized way to add 
a new agent to an automation provider.  Having said that, I think a lot of 
this scenario gets enabled by the rest of the work that needs to be done 
to accomplish that first goal.  Thus, I think it is a good scenario to 
discuss, but we may not (want or) be able to accommodate the entirety of 
the scenario in the first version of the spec.  And, I think the 
definition and semantics around an "AutomationTool" are likely to be too 
much to tackle this time around. 

> 
> To answer to Charles comments and questions: 
> 3. Exactly this is where this scenario fits into, Automation tool 
> picks up the Automaton Request created out of AutomationPlan to 
'execute' it 

I think I'm going to touch on this again down below in the discussion 
about AutomationResults, but it may (my concerns about standardizing 
AutomationTool interactions not withstanding) be time to start talking 
about cardinality of relationships here.  An AutomationPlan represents an 
arbitrarily large amount of work that may be distributed across an 
arbitrarily large number of systems.  The AutomationRequest was being 
discussed as a means to "execute" an AutomationPlan. So, it is a 
many-to-1, but each AutomationRequest represented a new "instance" of the 
AutomationPlan (as a whole) being executed.  In your scenario, I think the 
AutomationRequest is almost necessarily being tied to a more fine grained 
unit of work directed at a single system (or agent).  So, there feels like 
a bit of a disconnect between an AutomationRequest being a thing that 
represents the execution of the whole AutomationPlan and an 
AutomationRequest being a thing that represents a portion of the execution 
of an AutomationPlan.  Maybe the distinction ends up being irrelevant, but 
it feels "off" to me at the moment.

> 4. Automation tool query for work, query url provided by Automation 
> provider. It is automation server which decides where to look for work. 
[Snip]
>         4.2 Automaton request is not bound to any tool. Any tool 
> which polls first gets work assigned and then Automaton Request is 
> bound to that "ready" tool . 

I'm being picky here, but I want to poke on "gets work assigned".  Does 
the work get assigned simply because the agent updates the 
AutomationRequest to mark itself as the owner?  Or, was there something in 
the polling that was supposed to assign it to the agent (and then the 
agent goes back looking for static assignments to really get the work)? 
Or, perhaps some other undescribed mechanism?

> 5. I think most of these information are custom to the tool expect 
> some common properties I have observed 

The custom information is one of the things that bothers me with trying to 
standardize the server<-->agent communication.  If it's really custom, 
then we haven't actually standardized the interaction in a meaningful way 
(such that I can just use the spec to create a new agent to work with an 
arbitrary OSLC Automation provider).  But, trying to standardize it seems 
really difficult, as there are a *lot* of different agents running around 
out in the wild with varying different semantics and capabilities.

> 6. It is more about updating the progress of the Automation Request 
> we have been talking about. 
> I believe progress update (including taken), would be import part of
> Automation Request. 
> Essentially Automation Request has got a life cycle 
> Queued -> Taken -> In Progress ( 0%< progress <100%) -> Complete 
> (progress=100% or cancelled)
> 
> 9. Assuming there is an OSLC API to create AutomationResult, it 
> might be both either created or updated by the Automation tool 
> depending upon the need. 
>     An Automation Provider might create a place holder 
> AutomationResult and let Tool update it or just let Tool create the 
> result and update it back to Automation Request to link the data. 
>     e.g. An Automation Request might get cancelled before it can 
> complete. In that case it might not make sense always create resultsup 
front.
> Automation Result is not the place holder for anything else except 
> the actual result of running the automation. It make sense to 
> persist any temporary data like (status, messages, error, variables,
> snapshots etc) in the 
> Automation Request which relates to the governance of the the 
> execution activity. Automation Result is purely a result out of 
execution. 

I strongly disagree here (in particular with the comments about the 
purpose of the AutomationResult).  I believe the AutomationResult should 
always exist and represent the current state of the AutomationPlan 
"execution".  We have the notion of AutomatinContributions which will 
allow attaching (relatively) arbitrary information to the result.  And 
while we shouldn't limit the spec to only what current tools are capable 
of, I have big concerns with attaching to much information to the 
AutomationRequest resource as some of our key tools (Build Forge and RTC) 
aren't equipped to deal with it.  Build Forge doesn't even have the notion 
of this type of resource, and RTC has it, but doesn't store any real 
information there (only an indicator of whether the "automation" has been 
"taken" yet).  For both of these, the real status information is stored in 
the AutomationResult.

I'm getting a little ahead of myself, but I think we are going to 
ultimately want AutomationRequest to be somewhat loosely governed (e.g., 
you can create them, but they may not persist).  Perhaps it would be 
useful to talk about another resource, something like AutomationTask, that 
can hold status information related to a specific activity that is 
occurring as part of the larger AutomationPlan "execution".  I could see 
us spec'ing that an implementation doesn't have to support AutomationTasks 
at all, but, if they do, they must support XYZ capabilities.  Whereas for 
AutomationRequest, all tools MUST (or maybe just SHOULD) support it, but 
with much looser restrictions (lots of MAYs) around what it has to 
support.

Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386


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