[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction
Martin P Pain
martinpain at uk.ibm.com
Thu Aug 22 07:59:56 EDT 2013
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>
More information about the Oslc-Automation
mailing list