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 <[email protected]> To: [email protected], 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" <[email protected]> > 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 [email protected] 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
