On Thu, Apr 11, 2019 at 6:20 PM John Florian <[email protected]> wrote: > > On 4/10/19 3:06 AM, Yedidyah Bar David wrote: > > 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? > Here's an example. Please read ahead before digging into the log though. > > https://paste.fedoraproject.org/paste/956Bvf2UXzSwCSjxkD0OEQ/deactivate/vyLHHPInqQ2kz2Xr5KL55V2q2deoVEgmD1hNXtjcTtQQmljFU4gms2QoydmCTTvJ > > > > >> 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?) > 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? 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 _______________________________________________ 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/H7RNOKU3422GTE72LLJMOUQZC6MV34EB/
