9:58 a.m.
On Mon, Aug 26, 2019 at 2:13 PM <thomas(a)hoberg.net> wrote:
> Hi,
>
> On Thu, Aug 22, 2019 at 3:29 PM <thomas(a)hoberg.net> wrote:
>
> I assume this was successful. Did you check what packages were
> actually installed? Especially which were updated?
>
I went for minimal user actions, so things would be easy to repeat.
But while "yum groupinstall cinnamon" is only a single command, but it pulls
(and removes) the entire suite of Cinnamon desktop apps in one go, and with quite a few
dependencies all over the place.
I couldn't quite compare everything, but I checked all the obvious oVirt packages, so
everything with "*ovirt*, vdsm, otopi, cockpit, gluster etc.: Those had the very same
numbers.
>
> Before doing that, did you try disabling/removing full epel repo (only
> leaving enabled the parts enabled by ovirt-release* package)?
Yes, just disabling the epel-repo won't do the job...
>
>
> After installing Cinnamon?
>
...once Cinnamon is installed, installation as a host fails, because Python can't
find "rpmUtils".
If I remove Cinnamon (yum delete cinnamon; yum autoremove), it works again.
>
> This helps if there is a *conflict*, not sure it does much if epel has
> a newer version.
>
>
> Didn't understand "through some time of y miniyum".
ovirt-host-deploy,
I wouldn't either, I guess my fingers went into some kind of twist there ;-)
it should have ready "through some type of miniyum"
From what I understood reading the Python code there, the host deploy package is
importing an rpmUtils Python-package (aka miniyum)
rpmUtils is part of yum itself, in the yum libraries. miniyum is part of otopi.
to ensure that certain rpm-packages are either installed or pulled
for the host. And from what I also remember going through the Github sources, this
dependency on rpmUtils has been removed at some point
It was:
https://bugzilla.redhat.com/show_bug.cgi?id=1724056
But only for 4.4 (the next version).
> which what is ran on the host at that point, is based on otopi, and
> otopi has a yum plugin, and a miniyum module that it uses, and these
> indeed try to install/update packages. This is optional - if you want
> to prevent that, check "OFFLINE" section in:
Yes, and my question was mostly if this is running perhaps in some type of Python
chroot()/environment that's distinct from the 'normal' one on the target.
>
> https://github.com/oVirt/ovirt-host-deploy/blob/master/README
>
I'll have a look at that: Always better to satisfy dependencies early.
If you want a minimal installation, that already includes exactly what's
needed, you can also use ovirt-node :-)
>
On the book:
> Such a thing does not exist, and if it did, it will quickly become
> out-of-date, and quickly get worse over time. If you search around,
> you actually can find parts of it scattered around, as blog posts,
> 'deep dive' videos, conference presentations, etc. Part of these is
> indeed out-of-date :-(, but at least you can rather easily see when
> they were posted an which version was documented. And of course, you
> have the source! :-)
Yep, source is there, but without some backgrounder, it's a rocky journey... and I
have watched quite a few videos already and some blogs. Just don't know how far back I
should go, it's ten years, I believe...
I believe the problem here ocurrs in the context of Otopi, and all I have been able to
find on Otopi is that while the "human" mode is slightly better than the
"machine" mode for interactive use, it's not really meant to be an end-user
tool... A concept guide was nowhere to be found.
otopi itself was definitely not intended as an end-user tool. It's a
(small) framework for writing setup programs. The setup programs
themselves _are_ designed to be ran - engine-setup by end users,
host-deploy by the engine.
The closest to a "concept guide" you can find is:
https://www.ovirt.org/develop/developer-guide/engine/otopi.html
and the links from there, specifically a nice but very old and
partially outdated presentation.
>
>
> I'd start with:
>
> 1. Check host-deploy logs. You can find them on the engine machine
> (copied from the host) in /var/log/ovirt-engine/host-deploy. Compare
> failed and successful ones, especially around 'yum' - it should log
> the list of packages it's going to update etc.
Yup, looked at that, except that I couldn't quite find that list of packages: It
fails trying to satisfy the pre-conditions (missing rpmUtils), before trying to
check/install what it needs on the target.
>
> 2. Compare 'rpm -qa' between a failed and a working setup. Also 'yum
list
> all'.
Did that to exhaustion but not exhaustively...
Honestly, with the work-around (temporarily removing Cinnamon), it's not quite on the
critical path any longer... I sure want to solve that puzzle, but I am not sure just when
I'll be able to have another go at it.
That's very understandable. If it's indeed something specific to
Cinnamon, which I still find hard to believe, I guess we'll simply
wait until someone else runs into it and reports... I guess this
combination (engine or host with Cinnamon) is very rare. I guess
almost all setups of either the engine or hosts have no GUI installed
at all, and the few that do, probably use gnome.
If you still want to, you can open a bug, and attach all relevant
logs, including yum log and something like:
lastid=$(yum history | awk '/|/ && $1 ~ /[0-9]/ {print $1; exit}')
for id in $(seq $lastid); do
echo === ID $id ===
yum history info $id
done
>
>
> You mean attach to your email to the mailing list? Not sure you should
> see, but it's anyway considered better these days to upload somewhere
> (dropbox, google drive, some pastebin if it's just log snippets) and
> share a link. This applies to mails to the list. If you open a bug in
> bugzilla, please do attach everything directly.
I am using the Web-GUI not an e-mail client. I have been looking for some type of widget
which allows me to add an attachment there, but only gut a "send" or
"cancel" button.
I operate my Firefox in paranoid mode, no tracking/blocking ads-fingerprinting etc. so
some critical Javascript could fail.
Very well, you can still use some file upload service. I never used
the web interface for the users@ mailing list, no idea how it looks
like.
Best regards,
--
Didi