[Oslc-Automation] Minutes from 20130307

[Martin P Pain]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/bb2ca432/attachment-0003.html>