[Oslc-Automation] Bi-direction Actions/Auto spec dependencies, & action metadata at resource type (shape) level
Martin P Pain
martinpain at uk.ibm.com
Tue Sep 16 05:32:31 EDT 2014
(1) I've talked to Anamitra to make sure he has the meeting details and to
get him on the mailing list.
He won't need to use Automation to have the need to find the concrete
actions, but I'll let him talk about his scenario.
(2) The only "problem" I can see is not really a problem, just a slight
strangeness that Actions 3 might end up being the main spec to define the
usage of 2 terms in the Automation namespace (when we have the chance to
move it now). I'll see if I can get an opinion from Core on that.
Martin
"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
15/09/2014 17:38:54:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net
> Date: 15/09/2014 17:40
> Subject: Re: [Oslc-Automation] Bi-direction Actions/Auto spec
> dependencies, & action metadata at resource type (shape) level
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> I don't object to any of the potential changes discussed here in
> Martin's email.
>
> (1) I do want to be clear on motivating scenarios though.
>
> It's fair to say Anamitra does [would] need it *if his scenario
> requires the ability to select and configure an action "to be
> executed once it [the action]has been instantiated [actually becomes
> available]"). All I'm saying is that Anamitra should be the one to
> say if he needs that now, or forsees that need as a likely
> consequence even though he's not going to tackle it now. Maximo
> does not use Automation today, so it's not completely obvious to me
> that they'd ever have this need.
> (2) I do want to be clear on the resulting schedule. Remember I'm
> out for 3 weeks, starting later this week.
> Any change carries non-zero risk. I would say to some degree that
> when Anamitra's feedback on future actions arrived, we (certainly, I
> did this) intentionally *avoided* moving future actions down into
> Core, in part to mange the risk of the larger change. Would, for
> example, moving a function entirely between specs require us to
> restart the review process with Core? Not obvious to me.
> If we believe that "Actions 3.0" is going to be needed "soon
> enough", we might choose to do move the 'function' in 3.0 not 2.0.
> Core's guidance has been to lock down in-flight specs and move to
> OASIS. If the spec change doesn't affect implementations (which it
> should not, I believe is the commonly held assumption), what's
> leading us to "jam" it in now versus enter OASIS with a change that
> we'd really like to see on its work queue? Is it needed now, or is
> doing it now polishing the nose cone?
> Best Regards, John
>
> Voice US 845-435-9470 BluePages
> Cloud and Smarter Infrastructure OSLC Lead
> _______________________________________________
> 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/20140916/8503ed0c/attachment-0003.html>
More information about the Oslc-Automation
mailing list