[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction

[Martin P Pain]

Hi John,

Good point about that not coming through on the scenarios page. Having 
gone back and looked at it, we did cover it in the "Locating plans" 
section of [1] (while trying to be generic to any operations on the 
produced resource, not just teardown), but we didn't emphasise it 
elsewhere.

I've now updated the scenarios [2] [3] to include the actions of the User, 
which is where this requirement comes out.

I think your suggestion sounds like it would achieve what we need:
* The presence of the predicate perhaps ":teardown") on the Plan indicates 
that teardown is (likely to be) possible. 
* The value of the predicate is left open for future extensions or 
provider-specific information (such as a parameterised plan). Perhaps we 
could provide some terms that would be useful values for now, e.g. 
#required (i.e. highly desired) and #optional. But this isn't required to 
make this work.
* The predicate on the Result points to something to use to tear it down. 
We have to define exactly what, possibly one of:
   (a) A resource to DELETE
   (b) A resource to which to do a naked POST (I don't like this one)
   (c) An automation plan (with no [required] parameters) - this is 
extensible to other executable things, like Actions, although that 
wouldn't be interoperable/backwards-compatible.
   (d) A resource that tells the Client what to do. This would be flexible 
to point the client to do any of the above, but would require extra 
complexity on the client's side.

I feel fairly strongly about the link to the teardown plan going on the 
Result, to avoid imposing our vocab on other non-OSLC Auto resources.

I've written up a proposal based on this at [4].

With this approach I don't believe we would need produced/s for the basic 
teardown case. However, it might still be useful for other things, such as 
chaining together deployment & other plans in an orchestration plan, but 
that's for the orchestration discussions to cover.

Martin

[1] 
http://open-services.net/wiki/automation/Temporary-deployment:-%22Teardown-plan%22-property-on-Automation-Result/
[2] 
http://open-services.net/wiki/automation/Temporary-deployment-scenarios/
[3] 
http://open-services.net/wiki/automation/Temporary-deployment:-Service-virtualization-example/
[4] 
http://open-services.net/wiki/automation/Temporary-deployment:-%22Teardown-plan%22-property-on-Automation-Result/#Proposal-for-linking-to-teardown-plan-from-Result





From:   John Arwe <johnarwe at us.ibm.com>
To:     oslc-automation at open-services.net, 
Date:   21/08/2013 18:37
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>



> the desire to know in advance (at orchestration-plan design time) that 
teardown is possible, 

This requirement never really registered with me, let alone its primacy. 
Skimming the temporary deployment scenario pages, I don't see it coming 
through either.  Did I miss something, or is there a "composed plan design 
time" scenario driving this?  It seems reasonable enough, I see the same 
design vs run time issues certain places in CSI.  I've seen design-time 
scenarios drive subtly different requirements, so is there anything 
(content/properties) beyond mere capability needed to hit the mark for 
you? 

> and how to perform it. 

Let's assume something really simple: same predicate allowed on Plan and 
(either Result or the object of the :produced triple); you name the 
predicate. 

On the Plan, it's a general or incomplete hint ... it needs additional 
context, in the form of either the Result or the primary output resource 
(:produced), in order to be used as intended; I think we violently agree 
on that much. 

On the Result/:produced, it's one of the following: 

1: Completely specific to the request/:produced resource, as I laid out 
earlier.  Seems to meet RQM's goal. 

2: Same as on Plan, as you proposed earlier.  There was an unanswered 
question of how to pass the context resource in, as I remember.  Would 
have to work that out; given that we don't have namespace-qualified 
parameter names, I see us either 

2a: defining a well-known oslc_auto: URI for this plan (with a 
corresponding well-known parameter name) that providers could extend with 
optional parameters... seems to meet RQM's goal., or 
2b: saying it's implementation specific (which seems to defeat RQM's "not 
GreenHat-specific" interop goal). 

I think it's possible for GreenHat to actually implement #2 above via #1, 
although I grant I might be the only one so might need to make the "how" 
more explicit... and it definitely Would be implementation-specific, but 
still hidden from clients like RQM.  I'm not overjoyed at the prospect of 
defining a well-known oslc_auto: URI for teardown plans in general, but 
that might change as I learn more. 

We'd still need choose where the link goes (Result vs :produced); I don't 
have any strong feelings either way on that. 


Plan + :produces -> resource shape(s) for design time or UI-based 
introspection, sure fine makes perfect sense.  I can see that being useful 
with or without :produced, FWIW.  I'm guessing that it's 0:* since any 
given Plan could produce different resource(s) based on its input 
parameters. 

Stephen will have to chime in for his part; Michael is out this week, 
that's why I'm chairing. 
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/20130822/3c615eda/attachment-0003.html>