"Exception: Failed to create virtualenv" during packs.install about st2-packages HOT 13 CLOSED

probably related: #50

from st2-packages.

@dennybaa this one has higher priority, since it's blocker for puppet installer (where many st2 packages are installed).

from st2-packages.

https://stackstorm.slack.com/archives/stackstorm/p1450800171017578

from st2-packages.

Python bin directory location should NOT rely on PATH, it should use same mechanism which is used to locate python binary and fallback to PATH (optionally).

https://github.com/StackStorm/st2/blob/master/contrib/packs/actions/pack_mgmt/setup_virtualenv.py#L135

from st2-packages.

Just FYI there is actionrunner.python_binary option which allows you to specify which Python binary is used by the python runner action.

By default, that is the python binary which is used to run action runner process.

from st2-packages.

Fix for this issue is discussed here: StackStorm/st2#2339

from st2-packages.

I was able to work around this for actions by adding --always-copy to the virtualenv command here:
https://github.com/StackStorm/st2/blob/master/contrib/packs/actions/pack_mgmt/setup_virtualenv.py#L135

This allowed me to get the virtualenv created and to successfully run actions. The problem as it stands now is that sensors do not work. Since the virtualenv for the pack was created using the st2actions venv and not the st2reactor venv.

There were a couple other hacks to the packs pack necessary but that isn't relevant to this issue. I'll open a separate PR on those.

from st2-packages.

@DoriftoShoes nice, but we should not rely upon this work around... It's better setup_virtualenv.py is fixed to locate proper path to virtualenv binary. @Kami do you want me to try to implement this?

What comes to my mind, that we should get st2actionrunner (probably even st2 binary, i.e. python with which process is invoked) interpreter path, and evaluate virtualenv path accordingly. What do you think gentlemen?

from st2-packages.

@dennybaa @Kami: I was playing around with virtualenv paths and it doesn't make a difference. See gist here: https://gist.github.com/lakshmi-kannan/bddd20683f5fe4a49013

Patrick's --always-copy fixes the issue irrespective of which virtualenv binary is used. I will validate if this option works with existing packages.

from st2-packages.

Confirmed --always-copy works with existing packages. The difference in disk space between using --always-copy and not using it is below:

with --always-copy old packages
lakshmi@st2ops001:$ sudo du -sh /opt/stackstorm/virtualenvs/aws
52M /opt/stackstorm/virtualenvs/aws
lakshmi@st2ops001:$

without --always-copy old packages
lakshmi@st2ops001:$ sudo du -sh /opt/stackstorm/virtualenvs/aws
24M /opt/stackstorm/virtualenvs/aws
lakshmi@st2ops001:$

with --always-copy st2bundle packages
ubuntu@svetlana001:$ sudo du -sh /opt/stackstorm/virtualenvs/aws
50M /opt/stackstorm/virtualenvs/aws
ubuntu@svetlana001:$

from st2-packages.

@lakshmi-kannan , @here. Awesome, and thank you! I confirm that without copying (--always-copy) it won't work. However there's some positive researching from today. First let's cover fundamentals, based of course on my assumptions:))

First important: why virtualenv doesn't work without --always-copy or -p /usr/bin/python (system one).

• It's not clear totally how these above correlate, but invocation of virtualenv is not intended to run from another virtualenv. By design it's not relocatable...
• There's even an option --relocatable which makes existing virtualenv relocatable, but it doesn't work on 100%. So if you make our virtualenv relocatable using the switch, next you run ../virtualenv --system-site-packages /some/venv, not all of modules end up there, but a good point it that that virtualenv doesn't fail:)
• I've made some investigation, I found a way to completly copy via hardlinking prepared for relocation virtualenv here dennybaa/virtualenv-clone@ea8f9e0.

So just look, it's possible to run

# first we should preinstall virtualenv-clone
# second we need to make /usr/share/python/st2 relocatable using `--relocatable` switch
# then
/usr/share/python/st2/bin/virtualenv-clone /usr/share/python/st2 /tmp/vc

After this /tmp/vc looks fully functional.

Okay summing it up, it's possible to reduce virtualenv size to minimum (almost to 0) via hard linking.

But another important thing arises (upgrade story??), what is post upgrade st2 and pack story!? Using --always-copy freezes old st2 code inside a pack, same happens if we do hard linking. I.e. we upgrade st2 package and then we endup with outdated st2common, st2actions etc inside a pack... I have a few ideas, but we indeed need to discuss it, so we are not getting stuck at this point.

from st2-packages.

fixing last portion #76
So what we have:
All packages except el7 use:

virtualenv_opts = --always-copy

el7:

virtualenv_opts = 

from st2-packages.

i think closing. since already merged and tested using CircleCI...

from st2-packages.