Open Stack

On 08/27/2013 12:04 PM, Alessandro Pilotti wrote:
> 
> 
> 
> 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.

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