Aeolus Tech Cabal: 20/11/2012 - Minutes

Martyn Taylor mtaylor at redhat.com
Wed Nov 21 10:49:11 UTC 2012


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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20121121/002c2baf/attachment.html>


More information about the aeolus-devel mailing list