> -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: 24 February 2014 23:49 > To: openstack-dev@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
