Host reinstall: ModuleNotFoundError: No module named 'rpmUtils'
After mucking around trying to use jumbo MTU for my iSCSI storage nets (which apparently I can't do because my Cisco 3560 switch only supports 1500 max for its vlan interfaces) I got one of my Hosts screwed up. I likely could rebuild it from scratch but I suspect that's overkill. I simply tried to do a reinstall via the GUI. That fails. Looking at the ovirt-host-deploy log I see several tracebacks with $SUBJECT. Since Python pays my bills I figure this is an easy fix. Except ... I see this on the host: $ rpm -qf /usr/lib/python2.7/site-packages/rpmUtils/ yum-3.4.3-161.el7.centos.noarch $ python Python 2.7.5 (default, Oct 30 2018, 23:45:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Tab completion has been enabled.
import rpmUtils
I'm guessing this must mean the tracebacks are from Python 3 since I can clearly see the module doesn't exist for either Python 3.4 or 3.6. So this smells like a packaging bug somehow related to upgrading from 4.2. I mean, I can't imagine a brand new install fails this blatantly. Either that or this import error has nothing to do with my reinstall failure. -- John Florian
On Mon, Apr 8, 2019 at 1:06 AM John Florian <jflorian@doubledog.org> wrote:
After mucking around trying to use jumbo MTU for my iSCSI storage nets (which apparently I can't do because my Cisco 3560 switch only supports 1500 max for its vlan interfaces) I got one of my Hosts screwed up. I likely could rebuild it from scratch but I suspect that's overkill. I simply tried to do a reinstall via the GUI. That fails. Looking at the ovirt-host-deploy log I see several tracebacks with $SUBJECT.
Can you please share these logs?
Since Python pays my bills I figure this is an easy fix. Except ... I see this on the host:
$ rpm -qf /usr/lib/python2.7/site-packages/rpmUtils/ yum-3.4.3-161.el7.centos.noarch $ python Python 2.7.5 (default, Oct 30 2018, 23:45:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Tab completion has been enabled.
import rpmUtils
I'm guessing this must mean the tracebacks are from Python 3
Probably. Do you have it installed? In 4.3 we default to python3 if found. This is currently broken on EL7, and we decided to not fix. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1688811 This one is specifically about python34, and causes a different backtrace than yours. Now that 4.3 is out, I don't mind reverting this decision (of defaulting to python3) if it's considered premature, considering that most developers probably use master branches (4.4) by now (and that python3 support is still not finished :-(, although should work for host-deploy on fedora).
since I can clearly see the module doesn't exist for either Python 3.4 or 3.6. So this smells like a packaging bug somehow related to upgrading from 4.2. I mean, I can't imagine a brand new install fails this blatantly. Either that or this import error has nothing to do with my reinstall failure.
It's not a packaging bug. The way 'Add host' works is: 1. The engine creates a tarfile containing otopi + all needed modules/plugins (including host-deploy) and python libraries. This is cached, and you can check it if you want, at: /var/cache/ovirt-engine/ovirt-host-deploy.tar . 2. The engine ssh'es (is that a verb?) to the host, copies there the tar file, opens it, and runs it. Then, the code in it runs. You can find in engine.log the (long) command line it runs on the host via ssh. At this point, the code that runs there still can't do anything about packaging. In particular, it can't Require: any specific versions of anything, etc., because it's not installed by rpm but copied from the engine. But this is not really relevant. If you think this is a real bug, please (re)open one, and we'll think what we can do. Opinions/ideas are obviously welcome :-) Thanks and best regards, -- Didi
On 4/10/19 3:06 AM, Yedidyah Bar David wrote:
On Mon, Apr 8, 2019 at 1:06 AM John Florian <jflorian@doubledog.org> wrote:
After mucking around trying to use jumbo MTU for my iSCSI storage nets (which apparently I can't do because my Cisco 3560 switch only supports 1500 max for its vlan interfaces) I got one of my Hosts screwed up. I likely could rebuild it from scratch but I suspect that's overkill. I simply tried to do a reinstall via the GUI. That fails. Looking at the ovirt-host-deploy log I see several tracebacks with $SUBJECT. Can you please share these logs? Here's an example. Please read ahead before digging into the log though.
https://paste.fedoraproject.org/paste/956Bvf2UXzSwCSjxkD0OEQ/deactivate/vyLH...
Since Python pays my bills I figure this is an easy fix. Except ... I see this on the host:
$ rpm -qf /usr/lib/python2.7/site-packages/rpmUtils/ yum-3.4.3-161.el7.centos.noarch $ python Python 2.7.5 (default, Oct 30 2018, 23:45:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Tab completion has been enabled.
import rpmUtils
I'm guessing this must mean the tracebacks are from Python 3 Probably. Do you have it installed?
Yes, the host has both python34-3.4.9-3.el7.x86_64 and python36-3.6.6-5.el7.x86_64. These are required for some of my local packages.
In 4.3 we default to python3 if found. This is currently broken on EL7, and we decided to not fix. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1688811
This one is specifically about python34, and causes a different backtrace than yours.
Yup, but very informative just the same. For now, I'll just remove the extra stuff so that the host deploy can finish. I assume it's OK to have Python 3 installed for my things once the deploy is done. Is that a reasonable assumption? I mean, everything seemed to be running fine until I made the mess and tried using the host reinstall as a handy cleanup.
Now that 4.3 is out, I don't mind reverting this decision (of defaulting to python3) if it's considered premature, considering that most developers probably use master branches (4.4) by now (and that python3 support is still not finished :-(, although should work for host-deploy on fedora).
since I can clearly see the module doesn't exist for either Python 3.4 or 3.6. So this smells like a packaging bug somehow related to upgrading from 4.2. I mean, I can't imagine a brand new install fails this blatantly. Either that or this import error has nothing to do with my reinstall failure. It's not a packaging bug. The way 'Add host' works is:
1. The engine creates a tarfile containing otopi + all needed modules/plugins (including host-deploy) and python libraries. This is cached, and you can check it if you want, at: /var/cache/ovirt-engine/ovirt-host-deploy.tar .
2. The engine ssh'es (is that a verb?)
to the host, copies there the tar file, opens it, and runs it. Then, the code in it runs. You can find in engine.log the (long) command line it runs on the host via ssh.
At this point, the code that runs there still can't do anything about packaging. In particular, it can't Require: any specific versions of anything, etc., because it's not installed by rpm but copied from the engine. Good to know this! Just to make sure I read that right, you're saying
I think it should be. I use it all the time though it always sounds awkward. Text became a verb. Google became a verb. Why's this one so tough? :-\ Maybe its because it sounds like we trying to hush a crying baby. that "host deploy code" that runs on the host is not rpm packaged, but when that code runs it is installing rpms. So once it's done, everything that makes a host a host is via rpm, just not the "how" it got there. Am I right?
But this is not really relevant. If you think this is a real bug, please (re)open one, and we'll think what we can do. Opinions/ideas are obviously welcome :-)
Well, it doesn't sound like a bug as much as an expectation. I guess when I color outside the lines by adding my own local packages all bets are off. Still, I'm a little surprised how this one manifests since this kind of thing doesn't usually matter. I'm mostly a victim of my age and long experience of "if you want that on Linux, build it!" All these fancy automation tools (e.g., install host) are almost more difficult than the manual way ... but really that's only when they go wrong otherwise I often chuckle at the ease and what it takes to make that actually happen.
Thanks and best regards,
The thanks go to you! You responses are always helpful and greatly appreciated. The FOSS runs deep in you! -- John Florian
On Thu, Apr 11, 2019 at 6:20 PM John Florian <jflorian@doubledog.org> wrote:
On 4/10/19 3:06 AM, Yedidyah Bar David wrote:
On Mon, Apr 8, 2019 at 1:06 AM John Florian <jflorian@doubledog.org> wrote:
After mucking around trying to use jumbo MTU for my iSCSI storage nets (which apparently I can't do because my Cisco 3560 switch only supports 1500 max for its vlan interfaces) I got one of my Hosts screwed up. I likely could rebuild it from scratch but I suspect that's overkill. I simply tried to do a reinstall via the GUI. That fails. Looking at the ovirt-host-deploy log I see several tracebacks with $SUBJECT. Can you please share these logs? Here's an example. Please read ahead before digging into the log though.
https://paste.fedoraproject.org/paste/956Bvf2UXzSwCSjxkD0OEQ/deactivate/vyLH...
Since Python pays my bills I figure this is an easy fix. Except ... I see this on the host:
$ rpm -qf /usr/lib/python2.7/site-packages/rpmUtils/ yum-3.4.3-161.el7.centos.noarch $ python Python 2.7.5 (default, Oct 30 2018, 23:45:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Tab completion has been enabled.
import rpmUtils
I'm guessing this must mean the tracebacks are from Python 3 Probably. Do you have it installed?
Yes, the host has both python34-3.4.9-3.el7.x86_64 and python36-3.6.6-5.el7.x86_64. These are required for some of my local packages.
OK
In 4.3 we default to python3 if found. This is currently broken on EL7, and we decided to not fix. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1688811
This one is specifically about python34, and causes a different backtrace than yours.
Yup, but very informative just the same. For now, I'll just remove the extra stuff so that the host deploy can finish. I assume it's OK to have Python 3 installed for my things once the deploy is done. Is that a reasonable assumption? I mean, everything seemed to be running fine until I made the mess and tried using the host reinstall as a handy cleanup.
Yes, this should work. Alternatively, you can try this, on your hosts, before adding them: mkdir /etc/otopi.env.d echo 'OTOPI_PYTHON=/usr/bin/python' > /etc/otopi.env.d/my-python.env (Directory and extension are mandatory - we source *.env from there).
Now that 4.3 is out, I don't mind reverting this decision (of defaulting to python3) if it's considered premature, considering that most developers probably use master branches (4.4) by now (and that python3 support is still not finished :-(, although should work for host-deploy on fedora).
since I can clearly see the module doesn't exist for either Python 3.4 or 3.6. So this smells like a packaging bug somehow related to upgrading from 4.2. I mean, I can't imagine a brand new install fails this blatantly. Either that or this import error has nothing to do with my reinstall failure. It's not a packaging bug. The way 'Add host' works is:
1. The engine creates a tarfile containing otopi + all needed modules/plugins (including host-deploy) and python libraries. This is cached, and you can check it if you want, at: /var/cache/ovirt-engine/ovirt-host-deploy.tar .
2. The engine ssh'es (is that a verb?)
to the host, copies there the tar file, opens it, and runs it. Then, the code in it runs. You can find in engine.log the (long) command line it runs on the host via ssh.
At this point, the code that runs there still can't do anything about packaging. In particular, it can't Require: any specific versions of anything, etc., because it's not installed by rpm but copied from the engine. Good to know this! Just to make sure I read that right, you're saying
I think it should be. I use it all the time though it always sounds awkward. Text became a verb. Google became a verb. Why's this one so tough? :-\ Maybe its because it sounds like we trying to hush a crying baby. that "host deploy code" that runs on the host is not rpm packaged, but when that code runs it is installing rpms. So once it's done, everything that makes a host a host is via rpm, just not the "how" it got there. Am I right?
Exactly.
But this is not really relevant. If you think this is a real bug, please (re)open one, and we'll think what we can do. Opinions/ideas are obviously welcome :-)
Well, it doesn't sound like a bug as much as an expectation.
You are still welcome to file a bug, then.
I guess when I color outside the lines by adding my own local packages all bets are off. Still, I'm a little surprised how this one manifests since this kind of thing doesn't usually matter. I'm mostly a victim of my age and long experience of "if you want that on Linux, build it!" All these fancy automation tools (e.g., install host) are almost more difficult than the manual way ... but really that's only when they go wrong otherwise I often chuckle at the ease and what it takes to make that actually happen.
We definitely try to make oVirt work well for both experienced sysadmins that "know what they do" and for newbies (or simply way-too-busy-ones) that want a nice virtualization system but do not know linux too well.
Thanks and best regards,
The thanks go to you! You responses are always helpful and greatly appreciated. The FOSS runs deep in you!
Thanks :-) -- Didi
participants (2)
-
John Florian -
Yedidyah Bar David