[openstack-dev] [api] Forming the API Working Group

Christopher Yeoh cbkyeoh at gmail.com
Tue Oct 14 21:25:41 UTC 2014


On Tue, 14 Oct 2014 09:57:01 -0400
Jay Pipes <jaypipes at gmail.com> wrote:
> On 10/14/2014 05:04 AM, Alex Xu wrote:
> > There is one reason to think about what projects *currently* do.
> > When we choice which convention we want.
> > For example, the CamelCase and snake_case, if the most project use
> > snake_case, then choice snake_case style
> > will be the right.
> 
> I would posit that the reason we have such inconsistencies in our 
> project's APIs is that we haven't taken a stand and said "this is the 
> way it must be".

Not only have we not taken a stand, but we haven't actually told anyone
what they should do in the first place. I don't think its defiance on
the part of the developers of the API its just that they don't know
and without any guidance just do what they think is reasonable. And a
lot of the decisions (eg project vs tenant or instance vs server) are
fairly arbitrary - we just need to choose one.

> 
> There's lots of examples of inconsistencies out in the OpenStack
> APIs. We can certainly use a wiki or etherpad page to document those 
> inconsistencies. But, eventually, this working group should produce 
> solid decisions that should be enforced across *future* OpenStack
> APIs. And that guidance should be forthcoming in the next month or
> so, not in one or two release cycles.

I agree.

> 
> I personally think proposing patches to an openstack-api repository
> is the most effective way to make those proposals. Etherpads and wiki
> pages are fine for dumping content, but IMO, we don't need to dump
> content -- we already have plenty of it. We need to propose
> guidelines for *new* APIs to follow.

ok. I'm happy to go that way - I guess I disagree about us already
having a lot of content. I haven't yet seen (maybe I've missed them)
API guidelines suggestions from most of the openstack projects. But
lets just get started :-)

Chris



More information about the OpenStack-dev mailing list