Open Stack

I think we need a further constraint:

We must ensure that yum/etc believes that the python-* packages are installed.

There are a number of packages that we are currently purging in devstack due to the redhat/pip conflict which we cannot purge (e.g. python-lxml, python-c rypto) as they will remove things that depend on them.  Not only is this very antisocial but it is fatal to some configurations - such as Xen (which depends on python-lxml) with nova in dom0.  Currently devstack's removal of python-lxml forces the removal of xen.  I have no idea how many other packages are "just removed" from developer's systems and go un-noticed for a short period of time.

If we want to install a newer version of the python-* packages then we have to make sure the package manager for the OS knows that they are installed.

In my mind this restricts us to having to do something with RPMs - whether that is packaging all of the python components up as RPMs or using the dummy RPM proposed by Ian.

Out of these two, I think the cleanest solution for us is to use the dummy RPM for RPMs that we explicitly remove.  If this is only python-lxml and python-crypto (and maybe a couple of others) then this is probably fine.

One final thought - if we have to jump through lots of hoops to get this working correctly in devstack, then should we re-evaluate the use of virtual environments?  We're looking at departing a long way from how this can be deployed in the real world - so perhaps virtual environments would be a useful way to encapsulate what we're testing?

Bob 

> -----Original Message-----
> From: Dean Troyer [mailto:dtroyer at gmail.com]
> Sent: 05 August 2013 18:03
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro
> packages
> 
> [Moving a discussion from https://review.openstack.org/40019 to the ML
> to get a wider audience]
> 
> We've been around this block more than once so let's get it all
> documented in one place and see where to go next.  Skip down to
> ############# for more actual discussion...
> 
> Given:
> * OpenStack now has an official list of Python package versions
> required in https://review.openstack.org/p/openstack/requirements
> * This list is rarely completely available in any packaged Linux distro
> * Developers like new packages that fix their immediate problem
> * Packagers dislike the treadmill of constantly upgrading packages for
> many reasons (stability, effort, etc)
> * Running OpenStack on certain long-term-stability distros (RHEL6) is
> seriously a challenge due to the number of out-of-date components,
> specifically here many of the python-* packages.
> * Fedora and RHEL6 have a nasty configuration of telling pip to
> install packages into the same location as RPM-installed packages
> setting up hard-to-diagnose problems and irritating sysadmins
> everywhere.  FTR, Debian/Ubuntu configure pip to install into
> /usr/local and put '/usr/local/lib/python2.7/dist-packages' ahead of
> '/usr/lib/python2.7/dist-packages' in sys.path.
> * Replacing setuptools on RHEL6 illustrated another issue: removing
> python-setuptools took with it a number of other packages that
> depended on it.
> * OpenStack devs are not in the packaging business.  This has been
> decided [citation required?].  Fortunately those in the packaging
> business do contribute to OpenStack (THANKS!) and do make a huge
> effort to keep up with things like the Ububntu cloud Archive and Red
> Hat's RDO.
> 
> The last week or so of attempting to install Python prereqs from
> requirements.txt and installing pip 1.4 to support that rather than
> re-invent the wheel and all of the fallout from that illustrates
> clearly that neither approach is going to solve our problem.
> 
> Summary of the discussion in the review (paraphrased, read the review
> to see where I got it wrong):
> 
> * packages are evil: we develop and gate based on what is available in
> requirements.txt and a non-zero number of those are only in PyPI
> * Anvil solved this already: resolves requirements into the RPM
> package list and packages anything required from PyPI
> * ongoing worries about pip and apt/rpm overwriting each other as
> additional things are installed
> * packages are necessary:
> 
> #############
> 
> My specific responses:
> 
> * proposals to use a tool to automatically decide between package and
> PyPI (harlowja, sdague):  this works well on the surface, but anything
> that does not take in to account the dependencies in these packages
> going BOTH ways is going to fail.  For example: on RHEL6 setuptools is
> 0.6.10, we want 0.9.8 (the merged release w/distribute).  Removing
> python-setuptools will also remove python-nose, numpy and other
> packages depending on what is installed.  So fine, those can be
> re-installed with pip.  But a) we don't want to rebuild numpy (just
> bear with me here), and b) the packaged python-nose 0.10.4 meets the
> version requirement in requirements.txt so the package will be
> re-installed, bringing with it python-setuptools 0.6.10 overwriting
> the pip installation of 0.9.8.
> * separate proposal to build meta-packages (iwienand,
> https://review.openstack.org/39862): this would be an effective
> work-around for the problems on Fedora and RHEL6 and protect against
> the re-install problem, but this is solving a distro packaging problem
> in an upstream testing tool.  We would also need to manage these
> individually and not in a single large package, or at least split
> python-crypto and python-lxml out of the proposed package as they may
> not be installed in all configurations.
> * about-face on all-packages to all-PyPI (mtaylor): I'm still on the
> use packages where possible side but DevStack specifically is not in
> the packaging business.  If it were we'd do what Java folk (*sorry*)
> have long taken the approach for non-trivial apps to just include the
> whole damn runtime.  Write once duplicate everywhere.
> 
> I want to propose moving forward with the following guidelines:
> * Keep a list of specific distro packages that we want to use in favor
> of PyPI for specific reasons like not recompiling native modules, i.e.
> python-crypto except on RHEL, etc
> * Continue to factor the prereq setup out of stack.sh such that
> requirements.txt is satisfied one way or another before it begins to
> install OpenStack.  tools/install_prereqs.sh and tools/install_pip.sh
> are the prototypes for this. Each distro gets a chance to get it right
> here whether by package or by PyPI.
> 
> tl;dr: no easy solution
> 
> dt
> 
> --
> 
> Dean Troyer
> dtroyer at gmail.com
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev