On 08/27/2013 12:04 PM, Alessandro Pilotti wrote: > > > > On Aug 27, 2013, at 18:52 , Russell Bryant <rbry...@redhat.com > <mailto:rbry...@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.
Used by code *in the tree*. If you're backporting anything, you're on your own. I find it completely unreasonable to ask the upstream project to worry about supporting that kind of thing. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
