[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction
John Arwe
johnarwe at us.ibm.com
Wed Aug 21 13:37:40 EDT 2013
> 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>
More information about the Oslc-Automation
mailing list