<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 5, 2018 at 9:27 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 2, 2018, at 9:13 AM, Clark Boylan wrote:<br>
> On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:<br>
> > On 18-03-31 15:00:27, Jeremy Stanley wrote:<br>
> > > According to a notice[1] posted to the pypa-announce and<br>
> > > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0<br>
> > > is expected to be released in two weeks (over the April 14/15<br>
> > > weekend). We know it's at least going to start breaking[2] DevStack<br>
> > > and we need to come up with a plan for addressing that, but we don't<br>
> > > know how much more widespread the problem might end up being so<br>
> > > encourage everyone to try it out now where they can.<br>
> > ><br>
> ><br>
> > I'd like to suggest locking down pip/setuptools/wheel like openstack<br>
> > ansible is doing in<br>
> > <a href="https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt" rel="noreferrer" target="_blank">https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt</a><br>
> ><br>
> > We could maintain it as a separate constraints file (or infra could<br>
> > maintian it, doesn't mater).  The file would only be used for the<br>
> > initial get-pip install.<br>
><br>
> In the past we've done our best to avoid pinning these tools because 1)<br>
> we've told people they should use latest for openstack to work and 2) it<br>
> is really difficult to actually control what versions of these tools end<br>
> up on your systems if not latest.<br>
><br>
> I would strongly push towards addressing the distutils package deletion<br>
> problem that we've run into with pip10 instead. One of the approaches<br>
> thrown out that pabelanger is working on is to use a common virtualenv<br>
> for devstack and avoid the system package conflict entirely.<br>
<br>
I was mistaken and pabelanger was working to get devstack's USE_VENV option working which installs each service (if the service supports it) into its own virtualenv. There are two big drawbacks to this. This first is that we would lose coinstallation of all the openstack services which is one way we ensure they all work together at the end of the day. The second is that not all services in "base" devstack support USE_VENV and I doubt many plugins do either (neutron apparently doesn't?).<br>
<br>
I've since worked out a change that passes tempest using a global virtualenv installed devstack at <a href="https://review.openstack.org/#/c/558930/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/558930/</a>. This needs to be cleaned up so that we only check for and install the virtualenv(s) once and we need to handle mixed python2 and python3 environments better (so that you can run a python2 swift and python3 everything else).<br>
<br>
The other major issue we've run into is that nova file injection (which is tested by tempest) seems to require either libguestfs or nbd. libguestfs bindings for python aren't available on pypi and instead we get them from system packaging. This means if we want libguestfs support we have to enable system site packages when using virtualenvs. The alternative is to use nbd which apparently isn't preferred by nova and doesn't work under current devstack anyways.<br>
<br>
Why is this a problem? Well the new pip10 behavior that breaks devstack is pip10's refusable to remove distutils installed packages. Distro packages by and large are distutils packaged which means if you mix system packages and pip installed packages there is a good chance something will break (and it does break for current devstack). I'm not sure that using a virtualenv with system site packages enabled will sufficiently protect us from this case (but we should test it further). Also it feels wrong to enable system packages in a virtualenv if the entire point is avoiding system python packages.<br>
<br>
I'm not sure what the best option is here but if we can show that system site packages with virtualenvs is viable with pip10 and people want to move forward with devstack using a global virtualenv we can work to clean up this change and make it mergeable.<br></blockquote><div><br></div><div>Thanks Clark for looking into this. </div><div><br></div><div>One of the things that will break using a global virtual env is the "all-plugin" Tempest tox environment, which is still used in a few places [0].</div><div>The "all-plugin" tox environment is deprecated anyways, so this may actually push things moving in the right direction.</div><div><br></div><div>Some background the "all-plugin": Tempest plugins used to live in tree for many projects - for Tempest to discover those plugins, "all-plugin" installs Tempest in a virtual environment with system site-packages enabled. After the Tempest plugin community goal in Queens, most plugins are now hosted in a dedicated repository, and "all-plugin" should not be needed anymore.</div><div><br></div><div>Andrea Frittoli (andreaf)</div><div><br></div><div>[0] <a href="http://codesearch.openstack.org/?q=all-plugin&i=nope&files=&repos=">http://codesearch.openstack.org/?q=all-plugin&i=nope&files=&repos=</a> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Clark<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>