Open Stack

I've been doing continuous deployment via rpms on RHEL 6u3 of glance,
keystone,
neutron and nova for about six months now.  I used Anvil for the first three
months, but it required constant updating of dependency versions and it
didn't
support quantum.  Also, yum is terrible at managing dependency ranges, which
openstack components often have (e.g. SQLAlchemy>=0.7.8,<=0.7.9).  I'm not
convinced DNF[1] will be much better.

I found it easier to just build a virtualenv and then put all those files
in an
rpm.  Then make non-python dependencies (like libxslt) dependencies of that
rpm.
Since we did that the number of daily packaging headaches have dropped
significantly.   We have a bunch of Makefiles and jenkins jobs that drive
this
on every commit to components we care about.

I was unaware of RDO (or it hadn't been released) when I switched our builds
over.  I'd take a serious look at it, but right now I'm happy with our
solution.

[1] http://fedoraproject.org/wiki/Features/DNF


On Mon, Aug 5, 2013 at 10:03 AM, Dean Troyer <dtroyer at gmail.com> wrote:

> [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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130805/69cea02e/attachment.html>