[openstack-dev] [nova] Future of the Nova API

Kenichi Oomichi oomichi at mxs.nes.nec.co.jp
Tue Feb 25 02:39:04 UTC 2014


> -----Original Message-----
> From: Christopher Yeoh [mailto:cbkyeoh at gmail.com]
> Sent: Tuesday, February 25, 2014 6:35 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] Future of the Nova API
> 
> > - twice the code
> > - different enough to be annoying to convert existing clients to use
> > - not currently different enough to justify the pain
> 
> For starters, It's not twice the code because we don't do things like
> proxying and because we are able to logically separate out input
> validation jsonschema.
> 
> v2 API: ~14600 LOC
> v3 API: ~7300 LOC (~8600 LOC if nova-network as-is added back in,
> though the actually increase would almost certainly be a lot smaller)
> 
> And that's with a lot of the jsonschema patches not landed. So its
> actually getting *smaller*. Long term which looks the better from a
> maintenance point of view

The merits of jsonschema validation are not only less-code but also
clarifying API attributes Nova has.
Throght jsonschema validation development, we needed to clarify all API
attributes of each API and write all of them to API schema defined with
jsonschema. For example, https://review.openstack.org/#/c/68560/6/nova/api/openstack/compute/schemas/v3/scheduler_hints.py
clarifies that API extension scheduler_hints of "create a server" API
contains 7 API attributes and these data types. I think we don't have
enough API document which shows all API attributes.

So now I have a question what should deployers answer a question if
their users ask
  "What API attributes can we specify to your OpenStack API?"
to the deployers. Should we/deployers dig all v2 API code for all
API attributes? I think many people on this ML have this kind of
experience.
If all jsonschema patches are landed, we can show all API attributes
for deployers/users by just specifying API schema directory.


Thanks
Ken'ichi Ohmichi




More information about the OpenStack-dev mailing list