Hide Forgot
Description of problem: I was able to reproduce a failure with gdeploy playbooks where VDSM packages had been installed. I was using gdeploy to set up oVirt4+Gluster (HCI+HA). VDSM and Ansible both vend a module named mount.py, and the VDSM version trumps the Ansible version while the Ansible version is expected by gdeploy (e.g., in gdeploy/playbooks/mount.yml). Version-Release number of selected component (if applicable): How reproducible: Consistently reproducible Steps to Reproduce: 1. Install CentOS7 and enable extra pax (EPEL) 2. yum install ansible vdsm vdsm-gluster ovirt-hosted-engine-setup 3. git clone and build gdeploy master branch 4. compose gdeploy.conf with at least one mount point 5. invoke gdeploy Actual results: The error presenting when the VDSM module is discovered first is like "module (mount) is missing interpreter line" which is concurrent with the fact that the VDSM module named mount.py lacks a shebang. Expected results: The gdeploy-orchestrated Ansible deployment calls the mount module and the device becomes available. Additional info: I worked around this by copying the Ansible mount module to gdeploy/modules.
Moving to infra team as it seems like a vdsm fix Also adding Kasturi to see if this error has been encountered before?
I am not sure how mount.py in /usr/lib/python2.7/site-packages/vdsm/storage/mount.py can collide with mount.py in ansible. Can you provide more info like the logs and error messages?
root # cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) root # pwd /root root # git clone https://github.com/gluster/gdeploy.git root # pushd ./gdeploy root # ./gdeploy_setup.sh root # egrep -A8 '^\[lv.\]' ./gdeploy-ovirt-gluster.conf [lv1] action=create vgname=gluster lvname=engine lvtype=thick size=25GB mount=/gluster/brick1 [lv2] action=create vgname=gluster poolname=lvthinpool lvtype=thinpool poolmetadatasize=20MB chunksize=1024k size=70GB [lv3] action=create lvname=data poolname=lvthinpool vgname=gluster lvtype=thinlv mount=/gluster/brick2 virtualsize=50GB [lv4] action=create lvname=export poolname=lvthinpool vgname=gluster lvtype=thinlv mount=/gluster/brick3 virtualsize=50GB root # cat ./gdeploy/playbooks/mount.yml --- - hosts: gluster_servers remote_user: root gather_facts: no tasks: - name: Create the backend disks, skips if present file: path={{ item.path }} state=directory with_items: "{{ mntpath }}" - name: Mount the volumes mount: name={{ item.path }} src={{ item.device }} fstype=xfs opts="inode64,noatime,nodiratime" state=mounted with_items: "{{ mntpath }}" root # gdeploy --trace -vv -c gdeploy-ovirt-gluster.conf Using /etc/ansible/ansible.cfg as config file <...snip...> TASK [Mount the volumes] ******************************************************* task path: /tmp/tmpv0yJwQ/mount.yml:11 fatal: [hyp001.example.com]: FAILED! => {"failed": true, "msg": "module (mount) is missing interpreter line"} fatal: [hyp002.example.com]: FAILED! => {"failed": true, "msg": "module (mount) is missing interpreter line"} fatal: [hyp003.example.com]: FAILED! => {"failed": true, "msg": "module (mount) is missing interpreter line"} root # ln -sfvn /usr/lib/python2.7/site-packages/ansible/modules/core/system/mount.py /root/gdeploy/modules/ ‘/root/gdeploy/modules/mount.py’ -> ‘/usr/lib/python2.7/site-packages/ansible/modules/core/system/mount.py’ root # updatedb && locate -r /mount.py$|xargs ls -oghtr -rw-r--r--. 1 12K Jul 28 17:32 /usr/lib/python2.7/site-packages/ansible/modules/core/system/mount.py -rw-r--r--. 1 8.8K Sep 7 15:28 /usr/lib/python2.7/site-packages/vdsm/storage/mount.py lrwxrwxrwx. 1 69 Oct 21 09:14 /root/gdeploy/modules/mount.py -> /usr/lib/python2.7/site-packages/ansible/modules/core/system/mount.py # the brick dirs are already mounted in this example because gdeploy succeeded previously, but the aim is to demonstrate that the mount module is invoked successfully at all root # gdeploy --trace -vv -c gdeploy-ovirt-gluster.conf Using /etc/ansible/ansible.cfg as config file <...snip...> TASK [Mount the volumes] ******************************************************* task path: /tmp/tmpSZSMqR/mount.yml:11 ok: [hyp001.example.com] => (item={u'device': u'/dev/gluster/engine', u'path': u'/gluster/brick1'}) => {"changed": false, "fstab": "/etc/fstab", "fstype": "xfs", "item": {"device": "/dev/gluster/engine", "path": " /gluster/brick1"}, "name": "/gluster/brick1", "opts": "inode64,noatime,nodiratime", "src": "/dev/gluster/engine"} ok: [hyp002.example.com] => (item={u'device': u'/dev/gluster/engine', u'path': u'/gluster/brick1'}) => {"changed": false, "fstab": "/etc/fstab", "fstype": "xfs", "item": {"device": "/dev/gluster/engine", "path": " /gluster/brick1"}, "name": "/gluster/brick1", "opts": "inode64,noatime,nodiratime", "src": "/dev/gluster/engine"} ok: [hyp003.example.com] => (item={u'device': u'/dev/gluster/engine', u'path': u'/gluster/brick1'}) => {"changed": false, "fstab": "/etc/fstab", "fstype": "xfs", "item": {"device": "/dev/gluster/engine", "path": " /gluster/brick1"}, "name": "/gluster/brick1", "opts": "inode64,noatime,nodiratime", "src": "/dev/gluster/engine"}
(In reply to Kenneth Bingham from comment #3) > root # pushd ./gdeploy > root # ./gdeploy_setup.sh Regarding these lines of the transcript: I forgot to show 'popd'. The commands following were executed in /root.
(In reply to Kenneth Bingham from comment #3) root # ansible --version ansible 2.1.1.0 config file = /etc/ansible/ansible.cfg configured module search path = ['', '/root/gdeploy/modules/']
(In reply to Kenneth Bingham from comment #3) root # gdeploy --version gdeploy 2.0.1
Yaniv - can you take a look?
This may not be a vdsm issue, but an error setting Ansible module path according to gdeploy dev. Sachi, can you update bug?
(In reply to Sahina Bose from comment #8) > This may not be a vdsm issue, but an error setting Ansible module path > according to gdeploy dev. Sachi, can you update bug? As suggested by Kenneth, if Ansible happens to pick a <module-name>.py ahead of its modules. In this case mount, we see these kind of errors. Since these are mostly deployment scenarios, I'm not sure if we can fix them in the code. http://docs.ansible.com/ansible/developing_modules.html#module-paths explains some workarounds for such scenarios. Ramesh tried in-house with CentOS and gdeploy rpms with vdsm packages installed. And couldn't hit the error. Kenneth just curious, do you see similar issues when installing gdeploy from RPM[1]? [1]http://download.gluster.org/pub/gluster/gdeploy/LATEST/
I was unable to reproduce after installing the gdeploy rpm you prescribed because the executable produced only a traceback. root # /usr/bin/gdeploy -c gdeploy-ovirt-gluster.conf Traceback (most recent call last): File "/usr/bin/gdeploy", line 28, in <module> from gdeploylib import * File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeploylib/__init__.py", line 8, in <module> from call_features import call_features File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeploylib/call_features.py", line 25, in <module> import gdeployfeatures File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/__init__.py", line 9, in <module> import ctdb File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/ctdb/__init__.py", line 1, in <module> import ctdb File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/ctdb/ctdb.py", line 73 Global.logger.info("Executing %s."%) ^ SyntaxError: invalid syntax
Whelp, it's possible that the same problem exists in the Github repository master branch because I just switched my Ansible playbook back to the old method of running gdeploy/setup.py from a working copy of that repo and I got a different but similar traceback. root # /usr/bin/gdeploy -c gdeploy-ovirt-gluster.conf Traceback (most recent call last): File "/usr/bin/gdeploy", line 5, in <module> pkg_resources.run_script('gdeploy==2.0.1', 'gdeploy') File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 540, in run_script self.require(requires)[0].run_script(script_name, ns) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1455, in run_script execfile(script_filename, namespace, namespace) File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/EGG-INFO/scripts/gdeploy", line 29, in <module> from gdeploylib import * File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeploylib/__init__.py", line 8, in <module> from call_features import call_features File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeploylib/call_features.py", line 25, in <module> import gdeployfeatures File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/__init__.py", line 9, in <module> import ctdb File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/ctdb/__init__.py", line 1, in <module> import ctdb File "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/ctdb/ctdb.py", line 73 Global.logger.info("Executing %s."%) ^ SyntaxError: invalid syntax
(In reply to Kenneth Bingham from comment #10) > I was unable to reproduce after installing the gdeploy rpm you prescribed > because the executable produced only a traceback. > > root # /usr/bin/gdeploy -c gdeploy-ovirt-gluster.conf > Traceback (most recent call last): > File "/usr/bin/gdeploy", line 28, in <module> > from gdeploylib import * > File > "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeploylib/ > __init__.py", line 8, in <module> > from call_features import call_features > File > "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeploylib/ > call_features.py", line 25, in <module> > import gdeployfeatures > File > "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/ > __init__.py", line 9, in <module> > import ctdb > File > "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/ > ctdb/__init__.py", line 1, in <module> > import ctdb > File > "/usr/lib/python2.7/site-packages/gdeploy-2.0.1-py2.7.egg/gdeployfeatures/ > ctdb/ctdb.py", line 73 > Global.logger.info("Executing %s."%) > ^ > SyntaxError: invalid syntax Ken sorry about that. The commit https://github.com/gluster/gdeploy/commit/f51b790569 fixes it.
Can we close this bug, and track as an issue in gdeploy instead?
Due to comment #12