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.

On 4/10/19 3:06 AM, Yedidyah Bar David wrote: > On Mon, Apr 8, 2019 at 1:06 AM John Florian <jflorian(a)doubledog.org&gt; 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/v... > >> 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?) 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. > 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 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!