Open Stack

On 08/06/2013 02:44 PM, Mate Lakat wrote:
> Hi,
> 
> I would say, use a separated virtual environment in devstack - without
> the --system-site-packages switch, of course, and set it up as a user.
> Install the packages that are needed in order to be able to pip install
> them (like libxslt-dev). It's a development environment. I think my
> email is equivalent to a +1 to (Monty's change + virtualenv).

YUP - except we can't do it without system-site-packages, because of
nova and libvirt. We should still be ok though with a single venv, as
long as all of the installs into the venv use the -U flag to pip, which
will override the system env with teh venv one.

That said - I think there are a few different assumptions about what we
are trying to test that we need to sort out. Is the "we want to install
things globally via pip" an actual requirement, or one that has grown
out of implementation?

> On Tue, Aug 06, 2013 at 10:29:14AM -0500, Dean Troyer wrote:
>> 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
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>