Open Stack

On 08/08/2013 02:10 PM, Monty Taylor wrote:
> 
> 
> On 08/05/2013 02:03 PM, Dean Troyer 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
> 
> Yes. I think this will be helpful. It's essentially my about-face patch,
> which doesn't remove the installation of packages - with a general
> consensus that there will be specific distro packages that are needed to
> be there.
> 
> We're going to need to solve, particularly on RedHat, having a yum repo
> that someone maintains with yum packages of a couple of key things for
> at least a little bit. setuptools and pip are the two main ones right
> now. If we could have devstack on rh add a specific yum repo and yum
> install python-setuptools 0.9.8 and pip 1.4 early on, then I think most
> of our current major redhat issues would go away.
> 
> I don't think we will gain much by auto-generating packages. (believe
> me, I REALLY REALLY want to have the opposite opinion on that, and you
> can go troll the -infra logs for all the times where I've gotten angry
> and suggested we just go back to making packages) But there is a giant
> rathole we can wind up in there, and we'd essentially be making our own
> micro-distro, and I don't think that's the business we're in.
> 
> Similarly, I do not want to maintain additional repos as a general
> practice. Usually just pip installing the latest package works, or if it
> doesn't, waiting until the distro does a backport for us works. In some
> RARE cases (such as the current setuptools fiasco) the mechanics just do
> not allow us to deal with the situation in any other way. I think we
> need an answer for that, but I think it's VERY important that we are
> VERY careful with it.
> 
>> * 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

Dan, do you think devstack could leverage the smokestack repos for such build deps?
Maybe those deps are already there given that smokestack builds packages?
Though those repos probably aren't publicly available?

Alternatively we might carry these in a repo in RDO.
It seems appropriate for devstack to depend on RDO when run on Red Hat flavors.

If there are specific packages already available,
I can see about making available on RDO.

thanks,
Pádraig.