Open Stack

On 08/14/2013 06:25 AM, Chmouel Boudjnah wrote:
> 
> On Tue, Aug 13, 2013 at 11:58 PM, Alex Gaynor <alex.gaynor at gmail.com
> <mailto:alex.gaynor at gmail.com>> wrote:
> 
>     a) cffi-only approach, this is obviously the simplest approach, and
>     works everywhere (assuming you can install a PPA, use pip, or
>     similar for cffi)
>     b) wait until the next LTS to move to this approach (requires
>     waiting until 2014 for PyPy support)
>     c) Support using either netifaces or cffi: most complex, and most
>     code, plus "one or the other" dependencies aren't well supported by
>     most tools as far as I know.
> 
> 
> I think it sucks for large public cloud already in production to have to
> package a new python module and having to deploy it when most of them
> are pretty conservative with what goes in production, and we can't
> really assume they are going to update all their LTS to the new version
> when it's going to be released.

OpenStack decided to base its development efforts on latest ubuntu, not
'what's in latest LTS' back at the very beginning. This has not changed.
Since then, we have amended that to specifically include "shall not make
changes that are unreasonably difficult to backport to latest LTS and
latest RHEL" This is the reason (and the ONLY reason) that we haven't
killed support for python 2.6 - it is completely unreasonable to suggest
someone backport python 2.7 to RHEL right now.

I do not think it is unreasonable to backport cffi - especially when it
doesn't exist in Precise in the first place (you don't have to worry
about breaking things with a potentially incompatible version bump)
Also, OpenStack already uses cffi, and it's already in the
openstack/requirements file.

This isn't the only attempt to get rid of netifaces either. Neutron
removed it and replaced it with local code:

https://bugs.launchpad.net/neutron/+bug/1203663
https://review.openstack.org/#/c/38257/

Maybe an option d would be to see if the ip_lib code in neutron could be
used by swift as well? And if so, we could split that out into a library
that both projects could use?

Obviously, this is swift's decision - but the general policy of the
project he been target current and get distros to backport.

> Having said that there is people interested to know what performances
> improvement can come out from your work (thanks for that) to get PyPy
> support
> 
> If there is a vote I would go for c) then, potentially in the future we
> could unify it to just use cffi.
> 
> When you are saying 'plus "one or the other" dependencies aren't well
> supported by most tools as far as I know' are you talking about apt/pip
> etc..? I would assume that this is up to the distro packager which knows
> that the distro targetted have the cffi package. A far goes for
> pip-requires I would conservatively keep the dependence to netifaces.