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

[John Arwe]

> 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

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