On Mon, Apr 8, 2019 at 1:06 AM John Florian <[email protected]> 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 _______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/O5X4RPJSIPED6ZCBHYA4HTGMPUJLI3L6/
