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