[email protected] wrote on 10/13/2011 02:13:27 AM: > Pramod K Chandoria <[email protected]> > > 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
