[Oslc-Automation] OSLC Actions: Action for resource that does not yet exist: worked example

Martin P Pain martinpain at uk.ibm.com
Wed Jan 29 07:08:10 EST 2014


The scenarios example should be suitable for a top-to-bottom read if that 
is easier than reading through this email. However, read at least my 
response to items 1-3 first.

> Should        { <plans/1/results/67890> , oslc_auto:executes 
> , <plans/1/future-stop> } be 
>                 { <plans/1/results/67890> , 
> oslc_auto:executesAutomationPlan         , <plans/1/future-stop> } 
> in 2 places? 

It's one action pointing to another action, so I didn't use 
executesAutomationPlan as it's not pointing to an AutomationPlan. Other 
than that it's semantically very similar.

> "knows X/how" set of statements feels like it needs 
> capturing

I believe all occurrences of the word "knows" is now qualified as to 
"how", often with links to the specs.

> 1: "consumer is familiar with future actions, so it recognises that 
> results that are generated by executing this deployment plan will 
> have an action called “Tear down pattern 1”,"    Not seeing the 
> formal definition, I'm not sure that I can follow my nose with 
> respect to knowing where to look for the future action; we could 
> define that, if need be. 

I've now linked to the section in the Auto 2.1 spec (which has a new 
header) that talks about future actions, which explicitly defines which 
predicate to use and to place them on the Auto Plan.

> 2: "and it knows this is a teardown plan as it is of type 
> oslc:StopAction" ... not obvious how it knows that its 'teardown' 
> specifically.  Shirley (via the Open World Assumption) not always, 
> as currently written.  Maybe if you had a teardown type (in any ns). 

Sure, I'll change it to a teardown type. Added this to the scenario 
example and the Auto 2.1 spec, and linked the two.

> 3: "The consumer sees that there is a template dialog binding on the
> future action, and so knows that this action requires configuration"
> ... quibble: requires => likely accepts (and might require). 

Just double-checked, and the scenario doesn't contain a dialog for the 
teardown action, and we don't require one, so I'll take that out and leave 
it for future extension if anyone needs it. (The requires vs accepts thing 
sounds like to much of a can or worms - as well as "how does the consumer 
know whether it will be able to execute the bindings that it can't yet 
see".) Availablility may be able to make use of such a dialog, but I don't 
know if they care about the unattended execution case, especially for 
resources that don't exist at configuration-time.

I've also taken the equivalent normative text out of the Auto 2.1 draft 
spec, but left in a couple of notes.

I don't like taking this out, as I expect it could be likely for such a 
situation to require a dialog, but if we don't have the requirement right 
now and it wouldn't be a trivial add-on, I know it's best to leave it.
The only other issues is do we need to add something so that future 
extensions can prevent consumers that are used to the "no configuration 
needed" case as the only option from using future actions that use 
extensions that require dialogs for configuration, or that use bindings 
from a different profile. (Perhaps removing dialog doesn't solve the 
problem of "how does the consumer know whether it will be able to execute 
the bindings that it can't yet see".)

I've added in a template dialog earlier on in the example, as templates 
are still appropriate to this scenario.

> 4: "The Automation Request was never created to be executed in this 
> form by the provider " ... I think b/c of the oslc_auto:TemplateDialog 

This moved because of the change of location of the use of templates, but 
I hope it is clearer now.


> 5: "is encoded in the creation factory URI"

This now covers the two possible alternatives, as we are not using 
templates at this stage.

> 7: "this new request to determine when the teardown has completed. 
> When this new Automation Result " ... perhaps same as 6. 

These Request and Result don't have an example shown, but I have attempted 
to make that clear by giving them example URIs.

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
28/01/2014 21:36:03:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net, 
> Date: 28/01/2014 21:36
> Subject: Re: [Oslc-Automation] OSLC Actions: Action for resource 
> that does not yet exist: worked example
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> Should        { <plans/1/results/67890> , oslc_auto:executes 
> , <plans/1/future-stop> } be 
>                 { <plans/1/results/67890> , 
> oslc_auto:executesAutomationPlan         , <plans/1/future-stop> } 
> in 2 places? 
>
> When you say "the client knows", "The Automation Request was never 
> created to be executed in this form by the provider - only to be 
> downloaded to be submitted as a new Automation Request for executed 
> later. However, the way in which other providers behave may vary.)",
> and so on, I do find myself asking "how?, in other words "based on 
> what information?"  I can follow my nose through the steps (I 
> think), but I'm not positive that my answers would match anyone 
> else's ... that "knows X/how" set of statements feels like it needs 
> capturing even though I find myself hesitant to say it Must be. 
> Maybe this is a simple matter of completeness though - I see you 
> carefully leaving breadcrumbs in places before and after (e.g. in 
> resource context for the execute-later case). 
> Bottom line, I could follow it.  It required careful reading in 
> spots, but (given the two points in time, trying to link to 
> resources not yet created, etc) I don't think we can completely 
> stamp that out. 

> Taking a second pass, these are points where a breadcrumb might have
> been eaten by the crows. 

> 1: "consumer is familiar with future actions, so it recognises that 
> results that are generated by executing this deployment plan will 
> have an action called “Tear down pattern 1”,"    Not seeing the 
> formal definition, I'm not sure that I can follow my nose with 
> respect to knowing where to look for the future action; we could 
> define that, if need be. 

> 2: "and it knows this is a teardown plan as it is of type 
> oslc:StopAction" ... not obvious how it knows that its 'teardown' 
> specifically.  Shirley (via the Open World Assumption) not always, 
> as currently written.  Maybe if you had a teardown type (in any ns). 

> 3: "The consumer sees that there is a template dialog binding on the
> future action, and so knows that this action requires configuration"
> ... quibble: requires => likely accepts (and might require). 

> 4: "The Automation Request was never created to be executed in this 
> form by the provider " ... I think b/c of the oslc_auto:TemplateDialog 

> 5: "is encoded in the creation factory URI" this is true; I'm 
> tempted to change is => might be or "In this example, ..." since 
> it's not required (could also be in a fixed body). 

> 6: "As the Automation Request was created before the resource was 
> deployed, the request does not contain any context information" ... 
> "the" AutoReq, you have several - use its short URI, e.g. /56789? 

> 7: "this new request to determine when the teardown has completed. 
> When this new Automation Result " ... perhaps same as 6. 
> On the whole, for me, that's a pretty minor set of comments on 
> something this complex.  [worries: did he miss something?] 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140129/429e6027/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140129/429e6027/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140129/429e6027/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140129/429e6027/attachment.gif>


More information about the Oslc-Automation mailing list