[openstack-dev] [nova] Future of the Nova API
Jay Pipes
jaypipes at gmail.com
Fri Feb 28 16:21:58 UTC 2014
On Fri, 2014-02-28 at 11:35 +0000, Day, Phil wrote:
> > -----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,
Phew. Good to know my posy is agreeable :)
> 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.
No disagreement from me there! I don't see that as an issue. Having an
optional attribute in the response result is perfectly fine, as long as
it is documented. There's a difference between that and having to issue
different API calls entirely to do the same or a similar action
depending on what the underlying hypervisor or driver implementation is.
Examples of the latter include the how Nova supplies user and
configuration data to instances, as well as things like migrate,
live-migrate, and evacuate all being different API calls or API
extensions, when the operation is essentially the same...
Best,
-jay
More information about the OpenStack-dev
mailing list