On Mon, 24 Feb 2014 11:48:41 -0500 Jay Pipes <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
