> Hi,
> 
> On Thu, Aug 22, 2019 at 3:29 PM <thomas(a)hoberg.net&gt; 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) 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

> 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.
> 
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.
> 
> 
> 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.
> 
> 
> 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. 
> 
> Thanks and best regards,
> --
> Didi
Thank you!!
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
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/users@ovirt.org/message/XQV6BW4W5BRWLAKERQF25RG6UL2VZTKZ/

Reply via email to