Open Stack

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
>
> --
> Sean Dague
> IBM Linux Technology Center
> email: sdague at linux.vnet.ibm.com
> alt-email: sldague at us.ibm.com
>