Open Stack

On Tue, Aug 6, 2013 at 3:50 AM, Bob Ball <bob.ball at citrix.com> wrote:
> I think we need a further constraint:
>
> We must ensure that yum/etc believes that the python-* packages are installed.

If we want the rest of the system to use them, yes.

> 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.

Or knows to ignore them.  By keeping them away from the places the
package manager is likely to overwrite them with older versions.
Sounds like a venv?  Because it is, a
global-always-available-never-needs-explicit-acvtivation venv:
/usr/local

> 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.

The packaging work is already being done (will be done) for each
platform that wants to ship OpenStack.  It just isn't up-to-date with
development cycles.

> 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?

venvs, as implemented by the current tools, doesn't work well here.
BUT, if there was a single global venv available that could override
rpm-installed packages at will without disturbing them, would that
work?

BTW, that's how Debian/Ubuntu do it.  pip installs to /usr/local and
sys.path has it ahead of /usr

>> * 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.

I guess what I am saying is that if we're going to 'trick' something
on the system to behaving the way that we want, let's do the right
trick that doesn't have to be continually maintained.

dt

-- 

Dean Troyer
dtroyer at gmail.com