Aeolus Tech Cabal: 20/11/2012 - Minutes

marios@redhat.com mandreou at redhat.com
Wed Nov 21 16:21:04 UTC 2012


On 21/11/12 18:19, Martyn Taylor wrote:
> On 11/21/2012 12:40 PM, marios at redhat.com wrote:
>> On 21/11/12 12:49, Martyn Taylor wrote:
>>> Please find Aeolus Tech Cabal initial meeting minutes below.
>>>
>>> Next weeks Agenda can be found here:
>>> http://openetherpad.org/AeolusTechnicalCabal
>>>
>>> You must add items to the etherpad if they are to be discussed in next
>>> Cabal meeting.  Anyone wanting to add items to the Agenda then please do
>>> so by 26/11/2012.  This will give people a chance to do some
>>> preparation.
>>>
>>> Next meeting 27/11/2012
>>>
>> can we get a recording next time pretty please?  :)
> I'll see what we can do.  Alternatively you could always attend the
> meeting.

oh, and thanks - I assumed it was closed to members of the tech cabal only.

marios


>> marios
>>
>>> Regards
>>>
>>> Martyn
>>>
>>>
>>>   Aeolus Tech Cabal: 20/11/2012
>>>
>>>
>>>     Attendees
>>>
>>>   * Tomas Sedovic
>>>   * Martyn Taylor
>>>   * Jason Guiditta
>>>   * Scott Seago
>>>   * Eric Healms
>>>   * Michal Fojtik
>>>   * Greg Blomquist
>>>   * Jaramori Coufal
>>>
>>>
>>>     Agenda
>>>
>>>
>>>       Procedural Items
>>>
>>> *Meeting Format: Hugh will send format to the list before next Cabal
>>> Meeting*
>>>
>>>   * Meeting Time:
>>>       o 2pm Tuesday Recurring.
>>>       o   1 hour max.
>>>       o Items not covered will be raised in next meeting
>>>   * Awesome
>>>       o 1st Post: Martyn Taylor
>>>       o Respoibilities
>>>           +    Ensure agenda is adequate
>>>           + Ensure meetings move forward.
>>>   * Secretary:
>>>       o Weekly rotation: Next: Greg Blomquist
>>>       o Responsibilites
>>>           + Take Minutes
>>>           + Distribute Minutes
>>>
>>>
>>>     Technical
>>>
>>>
>>>       API Resource Representation.
>>>
>>> 1. When shall we use full resource and minimal (link) resource
>>>     representation in the API?
>>> 2. How should we allow client to access these resources?
>>>
>>> Martyn Proposed we represent full resources in all top level
>>> collections.  Sub resources will be represented as a collection (with
>>> url) when one to many relationship is present.  Sub resource collections
>>> will include minimal resources.
>>>
>>> Scott agreed this could solve many of the issues we are currently facing
>>> with the API and would be useful in the API.
>>>
>>> Greg mentioned that this could cause some issues with configure. But
>>> will seek advice from Eck
>>>
>>> Cabal voted in favour of proposal.
>>>
>>>
>>>         Actions:
>>>
>>>   * *Greg* will Confirm with Eck
>>>   * *Martyn* will send mail to list further explaining the proposal.
>>>   * *Martyn* will inform API contributers of changes.
>>>
>>>
>>>       Instance State Machine
>>>
>>> 1. How do we represent state changes in the API?  Particularly for
>>>     instances, deployments and deployables.
>>>
>>> Michal spoke about using actions and links that represent state changes.
>>>
>>> It was agreed that this is not strictly RESTful.  Discussion around pure
>>> REST v usability started, but the Cabal came to no conclusion on the
>>> matter.
>>>
>>> Michal advised us to take a look at the CIMI documentation
>>> (http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.1.pdf).
>>>
>>> Since the API resembles ours in many ways.
>>>
>>>
>>>         Actions:
>>>
>>>   * CIMI investigation
>>>   * Further discussion on the list.
>>>   * Initial topic next meeting.  (If unresolvable on list)
>>>
>>>
>>>       Outstanding Agenda Items
>>>
>>> 1. API versioning - Supporting for versioning the API (Not for
>>>     supporting multiple version)
>>>      1. URL v HTTP Header (Server HTTP header?)
>>>      2. e.g.
>>>       
>>> http://docs.openstack.org/api/openstack-identity-service/2.0/content/Versions-d1e472.html#d8e186
>>>
>>>
>>>
>>> 2. API Paging/Filtering/Sorting?
>>>      1.
>>> http://blog.apigee.com/detail/restful_api_design_can_your_api_give_developers_just_the_information
>>>
>>>
>>> 3. API Race Conditions
>>> 4. Handling Deltacloud exceptions in Deltacloud - What need to be done
>>>     to improve it..
>>> 5. Callbacks in Deltacloud - When, how and who :-)
>>>
>>>
> 
> 




More information about the aeolus-devel mailing list