On 21/11/12 18:19, Martyn Taylor wrote:
On 11/21/2012 12:40 PM, marios(a)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/Vers...
>>
>>
>>
>> 2. API Paging/Filtering/Sorting?
>> 1.
>>
http://blog.apigee.com/detail/restful_api_design_can_your_api_give_develo...
>>
>>
>> 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 :-)
>>
>>