[Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction
Stephen Rowles
stephen.rowles at uk.ibm.com
Thu Aug 22 10:40:27 EDT 2013
John, All,
Apologies, I won't be able to make the call today, I've been in other
meetings all day and will still be in them for the call. I've chatted with
Martin who will be able to represent my views for the purposes of the
discussion,
Stephen Rowles
From: John Arwe <johnarwe at us.ibm.com>
To: oslc-automation at open-services.net,
Date: 22/08/2013 13:48
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>
Martin, seems like a plan (heh) we can discuss on today's call at least.
Hopefully both you and Stephen can make it.
> * ... perhaps ":teardown") on the Plan ... value ...open for future
extensions or provider-specific information (such as a parameterised
plan). Perhaps ..., e.g. #required (i.e. highly desired) and #optional.
Certainly seems reasonable at first blush that Automation could make that
predicate's object a resource with it's own properties, and seed it with
those you propose which I interpret basically as usage hints. Let the
"spirited naming discussions" commence [ducks, as he always does for
those] on the predicate.
> * The predicate on the Result ... have to define exactly what, possibly
one of: ...
> (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.
To make use of a Plan, you also need a collection capable of fielding
create requests for that Plan. So this seems incomplete as written. Using
the same resource "trick" that I mused about on Plan would allow that,
even if the "shape" in this context is different. That's allowed.
One way to solve the compatibility issue (which, to be precise, is an
*implementation* issue not a spec issue, if the spec's Range is Any per
Core's guidance) would be to make it multi-valued, and make the semantic
that each of the possibly multiple values is functionally equivalent; a
client should choose at most one, presumably the one that it understands
best, if >1 are offered. If Automation provides one way to use that as a
current basis for wide interop *and* allows others for future extension,
implementation-specific extension, and/or implementation compatibility,
that seems like a pretty good situation.
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/3ac79dfb/attachment-0003.html>
More information about the Oslc-Automation
mailing list