Open Stack

On Tue, 2014-02-25 at 09:11 +1030, Christopher Yeoh wrote:
> 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.

OK, fair enough.

> 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.

Actually, the problem is not feature parity. The problem lies where two
drivers implement the same or similar functionality, but the public API
for a user to call the functionality is slightly different depending on
which driver is used by the deployer.

There's nothing wrong at all (IMO) in having feature disparity amongst
drivers. However, problems arise when the public API does any of the
following:

 * exposes two ways of doing the same thing, depending on underlying
driver
 * exposes things in a way that is specific to one particular
vendor/driver to the exclusion of others
 * exposes things that should not be exposed to the end-user or tenant,
but that belong in the realm of the deployer

See my original response on the ML about that for examples of all of the
above from the current Nova API(s).

Best,
-jay