Open Stack

On 08/08/2013 12:58 PM, Pádraig Brady wrote:
> 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.

I'd be more happy about depending on RDO - we already said that we're ok
with depending on Ubuntu Cloud Archive for Ubuntu flavors. Basically, I
don't want devstack to depend on repos that we don't think is reasonable
to tell end users who are going to deploy to actually depend on - but I
think UCA an RDO are reasonable to tell people they'll need if they want
to install from packages on those platforms.