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

Christopher Yeoh cbkyeoh at gmail.com
Mon Feb 24 22:41:49 UTC 2014


On Mon, 24 Feb 2014 11:48:41 -0500
Jay Pipes <jaypipes at gmail.com> wrote:
> It's not about "forcing" providers to support all of the public API.
> It's about providing a single, well-documented, consistent HTTP REST
> API for *consumers* of that API. Whether a provider chooses to, for
> example, deploy with nova-network or Neutron, or Xen vs. KVM, or
> support block migration for that matter *should have no effect on the
> public API*. The fact that those choices currently *do* effect the
> public API that is consumed by the client is a major indication of
> the weakness of the API.

So for the nova-network/neutron issue its more a result of either
support for neutron was never implemented or new nova-network features
were added without corresponding neutron support. I agree its not a
good place to be in, but isn't really relevant to whether we have
extensions or not.

Similarly with a Xen vs KVM situation I don't think its an extension
related issue. In V2 we have features in *core* which are only supported
by some virt backends. It perhaps comes down to not being willing to
say either that we will force all virt backends to support all features
in the API or they don't get in the tree. Or alternatively be willing
to say no to any feature in the API which can not be currently
implemented in all virt backends. The former greatly increases the
barrier to getting a hypervisor included, the latter restricts Nova
development to the speed of the slowest developing and least
mature hypervisor supported.

Chris



More information about the OpenStack-dev mailing list