Re: Aeolus Tech Cabal: 20/11/2012 - Minutes

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.

> 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 :-) >> >>