[openstack-dev] [nova] api schema validation pattern changes

Christopher Yeoh cbkyeoh at gmail.com
Tue Jan 14 03:45:29 UTC 2014

On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> We don't need API extensions and they make our Compute API laughably
> complex and cumbersome. We should ditch entirely the concept of API
> extensions in our next Compute API major release.
I think it way too late in the cycle to make this sort of change for the V3

> admin_actions -- seriously...why wouldn't pause/unpause, etc be part of
> the API? if some hypervisor doesn't support the action, then raise
> NotImplemented and return an HTTP 501 Not Implemented -- after all,
> that's what a 501 was designed for, and client tooling for HTTP APIs
> should understand that.
So interestingly the feedback we got at the HK design summit session around
is that we should split it up into multiple smaller extensions (and this is
going through
now). So deployers could more selectively deploy what they want to and not
include what
they don't want.

> And although we don't really have an official policy around it, I
> think the API extension functionality has been used as a way of
> allowing new functionality into Nova and evaluating it in place before
> deciding whether or not it becomes a core part of Nova.

I do understand this. But, I just think that it's mainly laziness that
> drives this. Instead of doing the hard work of determining a useful API
> structure ahead of time -- and validating that the new features actually
> fit the API audience -- it's just one more way of pushing immature or
> ill-fitting code into a codebase.
> Sorry for ranting.
Ranting is fine with me :-) But if its something we wanted to do for the V3
API we really should
have had this sort of discussion at the *Havana* design summit.

FWIW I think we're getting a lot better at doing quality control on APIs
which are added.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/89ef951d/attachment.html>

More information about the OpenStack-dev mailing list