> -----Original Message----- > From: Christopher Yeoh [mailto:cbky...@gmail.com] > Sent: Tuesday, September 23, 2014 7:39 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Nova] Some ideas for micro-version > implementation > > On Mon, 22 Sep 2014 09:47:50 -0500 > Anne Gentle <a...@openstack.org> wrote: > > > > > > (1) Input/Output attribute names > > > (1.1) These names should be snake_case. > > > eg: imageRef -> image_ref, flavorRef -> flavor_ref, hostId -> > > > host_id (1.2) These names should contain extension names if they > > > are provided in case of some extension loading. > > > eg: security_groups -> os-security-groups:security_groups > > > config_drive -> os-config-drive:config_drive > > > > > > > Do you mean that the os- prefix should be dropped? Or that it should > > be maintained and added as needed? > > > Originally (I think) the os- prefix was added to avoid potential > name clashes between extensions. Presumably out of tree extensions > too as in-tree ones would be picked up pretty quickly. For a while now > I've been thinking that perhaps we should just drop the os- prefix. > We're trying to discourage optional extensions anyway and I suspect that > the pain of maintaining consistency with os- prefixes is not worth the > benefit.
+1 for dropping os- prefix. On v2.1 API, these prefix makes inconsistency. > > > (3) Status code > > > (3.1) Return 201(Created) if a resource creation/updating finishes > > > before returning a response. > > > eg: "create a keypair" API: 200 -> 201 > > > "create an agent" API: 200 -> 201 > > > "create an aggregate" API: 200 -> 201 > > > > > > > Do you mean a 200 becomes a 201? That's a huge doc impact and SDK > > impact, is it worthwhile? If we do this change, the sooner the > > better, right? > > Ideally I think we'd want to do it when breaking a specific part of the > API anyway (for say some new feature). Otherwise its something I think > we should bring up on a case by case with users and operators. Trade > off between returning misleading status codes versus requiring > application side changes (potentially, some may just look for 2xx > anyway). > > > > > > > > > The TC had an action item a while back (a few months) to start an API > > style guide. This seems like a good start. Once the questions are > > discussed I'll get a draft going on the wiki. > > So back during the Juno design summit at the cross project API > consistency session we talked about putting together a wiki page with > guidelines for all OpenStack projects. But I think everyone got busy so > not much at all happened. I've had a bit of time recently and tried to > pull together info from the session as well as some other sources and > the start of it is here: > > https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines Thanks for updating the wiki. The above wiki is nice for our guideline. > So perhaps we could merge what is above into this wiki? > It is however still rather Nova specific and we need input from > other projects (I'll send out another email specifically about this). I agree, much input is necessary from other projects also for whole OpenStack consistency. Thanks Ken'ichi Ohmichi _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
