Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Gdeploy --version throws Error: "ImportError: No module named ansible.parsing.dataloader" on Rhel6 Version-Release number of selected component (if applicable): [root@dhcp43-151 ansible]# rpm -qa | grep gdeploy gdeploy-2.0.2-2.el6rhs.noarch How reproducible: Consistently Steps to Reproduce: 1.Install gdeploy on Rhel 6 2.Check gdeploy --version Actual results: Gdeploy version fails to show Expected results: Gdeploy version should be displayed Additional info: [root@dhcp43-151 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.9 Beta (Santiago) [root@dhcp43-151 ~]# rpm -qa | grep gdeploy gdeploy-2.0.2-2.el6rhs.noarch [root@dhcp43-151 ~]# gdeploy --version Traceback (most recent call last): File "/usr/bin/gdeploy", line 29, in <module> from gdeploylib import * File "/usr/lib/python2.6/site-packages/gdeploylib/__init__.py", line 5, in <module> from helpers import Helpers File "/usr/lib/python2.6/site-packages/gdeploylib/helpers.py", line 46, in <module> from ansible.parsing.dataloader import DataLoader ImportError: No module named ansible.parsing.dataloader -------- On installing Ansible on rhel 6, --------- [root@dhcp43-151 home]# gdeploy --version Traceback (most recent call last): File "/usr/bin/gdeploy", line 29, in <module> from gdeploylib import * File "/usr/lib/python2.6/site-packages/gdeploylib/__init__.py", line 5, in <module> from helpers import Helpers File "/usr/lib/python2.6/site-packages/gdeploylib/helpers.py", line 46, in <module> from ansible.parsing.dataloader import DataLoader File "/usr/lib/python2.6/site-packages/ansible/parsing/dataloader.py", line 36, in <module> from ansible.parsing.yaml.loader import AnsibleLoader File "/usr/lib/python2.6/site-packages/ansible/parsing/yaml/loader.py", line 30, in <module> from ansible.parsing.yaml.constructor import AnsibleConstructor File "/usr/lib/python2.6/site-packages/ansible/parsing/yaml/constructor.py", line 29, in <module> from ansible.vars.unsafe_proxy import wrap_var File "/usr/lib/python2.6/site-packages/ansible/vars/__init__.py", line 27, in <module> from jinja2.exceptions import UndefinedError ImportError: No module named jinja2.exceptions
This is due to ansible's selection of jinja2 package. [root@dhcp43-151 ~]# rpm -q --requires ansible /usr/bin/python2.6 PyYAML config(ansible) = 2.2.1.0-1.el6 python(abi) = 2.6 python-crypto2.6 python-httplib2 python-jinja2-26 ======= ansible chose to use jinja2-26 python-keyczar python-paramiko python-setuptools python-simplejson python-six rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 sshpass rpmlib(PayloadIsXz) <= 5.2-1 [root@dhcp43-151 ~]# And we still get jinja 2 errors posted in Comment #0 If we install jinja2 package separately: ======================== [root@dhcp43-151 ~]# rpm -qa |grep python-jinja2 python-jinja2-26-2.6-3.el6.noarch python-jinja2-2.2.1-3.el6.x86_64 [root@dhcp43-151 ~]# gdeploy --version gdeploy 2.0.2 [root@dhcp43-151 ~]# ======================= The solution is to add redundant package python-jinja2 for ansible on rhel6.
The similar test case used to pass in 3.2. The regression is not due to gDeploy but due to a package dependency change in upstream Ansible the test case is failing.
Commit: https://github.com/gluster/gdeploy/commit/057a735 fixes the issue.
Verified this bug on # rpm -qa | grep gdeploy gdeploy-2.0.2-3.el6rhs.noarch # gdeploy --version Error: Ansible(>= 2.2) is not installed. Some of the features might not work if not installed. gdeploy 2.0.2 Installing: gdeploy noarch 2.0.2-3.el6rhs /gdeploy-2.0.2-3.el6rhs.noarch 2.5 M Installing for dependencies: PyYAML x86_64 3.10-3.1.el6 RH-6.9-Server 157 k libyaml x86_64 0.1.3-4.el6_6 RH-6.9-Server 52 k python-babel noarch 0.9.4-5.1.el6 RH-6.9-Server 1.4 M python-jinja2 x86_64 2.2.1-3.el6 RH-6.9-optional 466 k python-jinja2 is now pulled in as dependent package while installing gdeply. Moving this bug to verified state
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2776