Open Stack

On Aug 27, 2013, at 18:52 , Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>>
 wrote:

On 08/27/2013 10:53 AM, Alessandro Pilotti wrote:
That's IMO a different story: backporting a driver is usually quite
trivial as it affects only one service (nova-compute) and one
interaction point with Nova (the driver's interface). Between Havana and
Grizzly for example, the entire Hyper-V driver can be backported without
substantial issues. On the deployment side, we have to care only about
updating the code which runs con the compute nodes, using vanilla
OpenStack components on the controller and remaining nodes.

Backporting the public APIs is a whole different story, it affects way
more components that need to be deployed (nova-api as a minimum of
course), with way more interaction points that might incur into patching
hell.

Do you really know that?  This is pretty hand wavy.  I think you're
making this backport out to be _way_ more complicated than it is.  I
don't see why it's any more complicated than a virt driver feature backport.

No, that's why I used "might" instead of "will" :-)

More important than the coding issue, there's the deployment and support issue for additional components that need to be mantained outside of the main code repo.

What about publishing the API as blacklisted by default? This way it
would be available only to users that enable it explicitly, while still
supporting the scenario described above.
It still makes no sense to me to merge an API for a feature that can't
be used.

This depends on the definition of "can't be used":

It's a feature that can't be used in the Havana code base, but I can assure you that we would do good use of it by backporting the "I" code.



--
Russell Bryant

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130827/4ad37095/attachment.html>