Last modified: 2014-07-03 13:07:46 UTC
Zuul next version depends on the python module six version 1.4.1 to abstract out url lib. We need some more recent version to be backported. No usage in puppet, package has no reverse depends. Might have no impact to backport it.
The build process of source package 'six' depends on python-pytest :-/
During the Zurich Hackathon in May 2014 Alexandros looked at hosts having python-six installed: {'copper.eqiad.wmnet': 'YES'} {'labnet1001.eqiad.wmnet': 'YES'} {'osmium.eqiad.wmnet': 'YES'} {'tantalum.eqiad.wmnet': 'YES'} {'virt1000.wikimedia.org': 'YES'} {'virt1001.eqiad.wmnet': 'YES'} {'virt1002.eqiad.wmnet': 'YES'} {'virt1003.eqiad.wmnet': 'YES'} {'virt1004.eqiad.wmnet': 'YES'} {'virt1005.eqiad.wmnet': 'YES'} {'virt1006.eqiad.wmnet': 'YES'} {'virt1007.eqiad.wmnet': 'YES'} Because python-six is a depends of OpenStack bricks: $ apt-cache rdepends python-six python-six Reverse Depends: python-neutronclient python-nova python-wsme python-warlock python-urllib3 python-pecan python-oslo.config python-novaclient python-nova python-neutronclient python-neutron python-keystoneclient python-heat python-glance python-cinderclient python-cinder python-ceilometer So upgrading python-six would impact labs / OpenStack infrastructure and I have no clue of the impact of such an upgrade. CCing ops: Alexandros, Marc-Andre and Andrew B.
It is indeed, but AFAIK OpenStack specifies only a minumum version and shouldn't break. That said, depending on the timeline, we might get to actually test this without risking breakage: when we set Dallas up we can simply try to build the OpenStack cluster against the newer version and test it.
Any rough estimate when the cluster will be added to Dallas? :)
If the general estimate is that OpenStack won't break, we can just upgrade the current installation and just watch out for problems. Worst case scenario is we will have to downgrade again. That will also help unblock Antoine's work a lot faster than for him waiting for Dallas. I am volunteering to help with the upgrade/downgrade but I do not know what problems to watch out for.
Another solution would be to install python-six in a repository, deploy it via git-deploy and find out a way to have Zuul point to it (via PYTHONPATH probably). That might be safer but I am not sure it is worth the overhead.
Turns out python-six is only needed for Zuul tests so we can postpone the backport undefinitely or just wait for Trusty :) Sorry for the trouble. Setting low priority.
Having the package backported with the version needed by Zuul is quite unlikely. Instead I will provide the python-six tarball along with Zuul source code.
