Thanks for the comments - I've added them to the minutes since your e-mail was not very well formatted in the mailing list archives.
We'll discuss in the meeting today. Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170 Martin P Pain <[email protected] m.com> To Sent by: [email protected], "Oslc-Automation" cc <oslc-automation- bounces@open-serv Subject ices.net> Re: [Oslc-Automation] Minutes from 20130307 04/04/2013 09:19 AM I can't remember the meeting well enough to link the points in the minutes to what was said in the meeting, but these are my thoughts on what's recorded in the minutes (some of these thoughts recover some of the things said in the meetings which I don't think the minutes cover sufficiently, others are new thoughts - I'm not entirely certain which are which): Discussion point 1: "Martin does not believe more than a simple flag is not needed, but can investigate" should be "Martin does not believe more than a simple flag is needed, but can investigate" Discussion point 2: I don't like the word "environments". If we are talking about deployment, I prefer the term "deployed resource(s)" to be completely ambiguous about what was deployed. I hope we should be able to talk about it in the singular - represented by the single automation result - even if there are 1000s of compute/network resources. Therefore any "link in result contribution" would be to some other domain/protocol's representation of the same thing that the automation result represents - it would not be linking to anything defined in the OSLC auto spec. I see the auto result as representing the complete set of "deployed resources" or, if only one resource was deployed, then I see it as representing that "deployed resource" itself, not merely being an intermediate piece of RDF holding state and a link to a representation of the deployed resource. But I unerstand others' views may vary on this. Discussion point 3: I consider the orchestrator & the provider who did the initial deployment (if you mean the composite deployment, rather than the individual components) to be the same actor. And yes, it is that actor who is responsible for the teardown. Then the component results/resources are torn down by the 'client' who set them up (in this case the orchestrator), which from the point of view of the component providers is exactly the same as if it were controlled from a simple client not an orchestrator. The "likely (?) has a corresponding plan for teardown" comment, if I understand it correctly, refers to one of the possible approaches for representing teardown, and is not the one I suggest we take. Discussion point 4: If consumers are programmed to be aware of multi-use (as I would suggest this only be a MAY-level req on the client's side) then they would know which property to look at in the auto result representation to see other clients who are registered as using it, IF we decide to have the link from the auto result to the client identifier (which is my suggested direction). If we have the link in the other direction, then the multi-use-aware clients would know what query toperform to find this out on the provider. If we allow cross-provider links, then we need some way for the clients to look up which other providers they should query (and this complexity is why I suggest the links from auto result to client). Discussion point 5: Will reply to mailing list thread. Martin 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 _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
