Aeolus Tech Cabal: 20/11/2012 - Minutes

marios@redhat.com mandreou at redhat.com
Wed Nov 21 12:40:10 UTC 2012


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

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