Open Stack

On 11/1/12 11:04 AM, "Anne Gentle" <anne at openstack.org> wrote:

>Hi Sean,
>Thanks for the round-up.
>
>On Thu, Nov 1, 2012 at 6:57 AM, Sean Dague <sdague at linux.vnet.ibm.com>
>wrote:
>> Going back through the nova-api-consistency session
>> (https://etherpad.openstack.org/grizzly-nova-api) I think I've
>>extracted all
>> the actions out of it that we need to tackle. Wanted to float this past
>>the
>> list (and the same for relevant nova and qa meetings later today) to
>>sanity
>> check with the rest of the community.
>>
>> Blueprint: apis-for-nova-manage
>> (https://blueprints.launchpad.net/nova/+spec/apis-for-nova-manage).
>>Already
>> in progress by cyeoh and others. This helps deal with one of the big API
>> holes in nova.
>>
>> TODO (Blueprint?): automated way to sync nova sample api tests to
>> api.openstack.org. Does the doc team use blueprints? Mauro, Anne, and I
>> discussed this the other day, Mauro's going to propose some approaches.
>
>We do use blueprints for projects like this - see
>https://blueprints.launchpad.net/openstack-manuals/+specs?show=all for
>both in progress and implemented.
>
>> Blueprint: nova-v3-api - create a blueprint for the nova v3 api, and
>> equivalent wiki page describing that nova-v3 is expected to be return
>>code
>> consistency cleanup, ordering and pagination cleanups relative to Gabe's
>> overall API consistency effort, and the promotion of a couple critical
>> extensions. We'll hash out details in the wiki. Additionally a set of
>>tags
>> for bugs: v2-api-bug, v2-api-inconsitency, v2-api-missing for things
>>that
>> need to be address in a v3 api.
>
>Huzzah for promoting critical extensions. How do you want to handle
>this in the docs? Do we update the spec? Or complete new user docs?
>
>>
>> TODO (Blueprint?): nova-api audit - go through the existing nova API
>>with a
>> fine toothed comb and figure out the various return usage today, and
>>expose
>> more of the inconsistencies we find. The output of this is additional
>>unit
>> tests and bugs for fix in v3 api. It's a big chunk of work, but not a
>>big
>> chunk of code, so is blueprint the right artifact for this?
>>
>> TODO (Blueprint?): get expected error codes as part of the
>>api.openstack.org
>> site. Requires enhancing the mavin plugin that generates that site.
>>Working
>> with Anne on the approach now.
>
>Any UI designers itching to draw it up before we enhance the maven
>plugin? I've also thought we could have a separate reference page for
>each API - thoughts? Might help the designer if it wasn't a super long
>page.
>
>Thanks Sean for parsing through all these bits and pieces.
>Anne
>
>>
>> TODO (Blueprint?): wiki guide for API writers on guidelines for
>>creating new
>> APIs (for nova, especially extensions). This will clearly need to be
>>done in
>> very close contact with Gabe when he kicks off the overall API
>>consistency
>> work. Expect this is probably really a sub task of that work.
>>
>> Comments and critiques welcomed,
>>
>>         -Sean

Definitely a big thanks Sean.

I think there was something else in this session we talked about that
wasn't captured in the ether pad (also possible it was another session).
We need to start thinking about notifications a bit more rigorously as
well.  Versioning the notifications and treating them as another
(readonly) API.  I'm not sure if it should be included in the same set of
blueprints, or just done independently, but I want to make sure we don't
forget that thread. Seems like we need a blueprint to start versioning if
there are changes we want to make to the notifications format.  In
addition we may need a blueprint to determine some possible strategies for
supporting the venting of multiple notification versions.  I'm happy to
work on those as long as no one else has them.

Gabe


>>
>> --
>> Sean Dague
>> IBM Linux Technology Center
>> email: sdague at linux.vnet.ibm.com
>> alt-email: sldague at us.ibm.com
>>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev