Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: 24 February 2014 23:49
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Future of the Nova API
> 
> 
> > 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.

I agree with the rest of your posy Jay, but I  think there are some feature parity issues - for example having rescue always return a generated admin password when only some (one ?) Hypervisor supports actually setting the password is an issue. 

For some calls (create , rebuild) this can be suppressed by a Conf value (enable_instance_password) but when I tried to get that extended to Rescue in V2 it was blocked as a "would break compatibility - either add an extension or only do it in V3" change.   So clients have to be able to cope with an optional attribute in the response to create/rebuild (because they can't inspect the API to see if the conf value is set), but can't be expected to cope with in the response from rescue apparently ;-(

 Phil