Infrared failing while installing the undercloud node

[Kosal-Raj]

// I am facing the error for RHOSP 10, 11 & 12

TASK [shade : install virtualenv pip module] **** fatal: [hypervisor]: FAILED! => {"changed": false, "cmd": "/usr/bin/pip2 install virtualenv==15.0.3", "msg": "stdout: Collecting virtualenv==15.0.3\n Downloading virtualenv-15.0.3-py2.py3-none-any.whl (3.5MB)\nInstalling collected packages: virtualenv\n Found existing installation: virtualenv 1.10.1\n\n:stderr: Cannot uninstall 'virtualenv'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.\n"}

NO MORE HOSTS LEFT ** to retry, use: --limit @/root/.venv_infrared/infrared/plugins/tripleo-undercloud/main.retry

PLAY RECAP ** hypervisor : ok=10 changed=5 unreachable=0 failed=1
localhost : ok=7 changed=4 unreachable=0 failed=0
undercloud-0 : ok=41 changed=26 unreachable=0 failed=0

ERROR Playbook "/root/.venv_infrared/infrared/plugins/tripleo-undercloud/main.yml" failed!

[obaranov]

@Kosal-Raj, hey Looks like there is a conflict with the virtualenv pip package installed on your hypervisor and with the version of that package required by infrared. I'd suggest to update manually that package on your hypervisor to the recent version (at least to the 15.0.3).

[eprasad]

The virtualenv pip package was conflicting with python-virtualenv rpm package installed on the system, to fix this, I simply removed python-virtualenv rpm from the hypervisor and then re-installed it using pip. Now, tasks from infrared/infrared/common/roles/shade/tasks/main.yml playbook executing successfully.

While checking the infrared/infrared/common/roles/shade/tasks/main.yml, I found the virtualenv version is hardcoded, instead of that, can we use latest?

from :

pip: name: virtualenv version: 15.0.3 to:

pip: name: virtualenv state: latest

[obaranov]

@eprasad, I believe usage of the 'latest' is not always safe. We can get newer version with some API changes or with some issues, etc. This might not be true for that particular package, but in general we are trying to pin packages versions to have more stability and avoid failures because of 3rd party tools.

[eprasad]

@obaranov , Thanks for explaining why we pin package versions. I now totally agree with you that package versions should be pinned.

[Kosal-Raj]

Thanks @obaranov and @eprasad . I was able to bypass this issue.