Aeolus Tech Cabal: 20/11/2012 - Minutes
marios@redhat.com
mandreou at redhat.com
Wed Nov 21 16:21:04 UTC 2012
On 21/11/12 18:19, Martyn Taylor wrote:
> On 11/21/2012 12:40 PM, marios at 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/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