[Oslc-Automation] Minutes from 20130307

Thu Apr 4 09:49:45 EDT 2013

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
fiedler at us.ibm.com
919-254-4170

             Martin P Pain                                                 
             <martinpain at uk.ib                                             
             m.com>                                                     To 
             Sent by:                  oslc-automation at open-services.net,  
             "Oslc-Automation"                                          cc 
             <oslc-automation-                                             
             bounces at 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
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/fb69b519/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/fb69b519/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic27191.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/fb69b519/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130404/fb69b519/attachment-0002.gif>