Le 06/02/2019 à 15:42, Greg Sheremeta a écrit :
On Wed, Feb 6, 2019 at 6:33 AM Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 06/02/2019 à 10:53, Lucie Leistnerova a écrit :
>
> On 2/6/19 10:22 AM, Nicolas Ecarnot wrote:
>> Hi Lucie,
>>
>> Le 06/02/2019 à 10:02, Lucie Leistnerova a écrit :
>>> I'm sorry, my mistake I did not mention to remove the package without
>>> dependencies.

Same -- sorry, ugh.
For anyone in the same situation, the better thing to do now is simply 'yum update ovirt-engine-ui-extensions'
That will remove the old dashboard correctly.
https://github.com/oVirt/ovirt-engine-ui-extensions/blob/master/packaging/spec.in#L16


Thank you. We need this kind of wheels greasing as oVirt's complexity increases.




To sum up, I think what I'm missing is a clear and solide documentation
or official Redhat message about whether/what/how/when can/cannot we
update (with "yum update") the engine host and/or the hosts.

Not Red Hat -- oVirt :)

Yep, Greg Sheremeta <gshereme@redhat.com> ;-)

Indeed, we need an Upgrade Guide update. I'll look into it.

Generally, on my dev instances (which are probably nowhere near as complicated as your setups), I run 'yum update' followed by 'engine-setup'.

Actually, my experience is that yum-upgrading the engine was most of the times harmless, but yum-upgrading the hosts lead to complex situations.

I'm at a point where I no longer update my hosts with yum update, and only relies on oVirt's update (either via the web GUI or ansible's cluster upgrade) which only updates part of the packages.

I'd rather have a strong enough RPM environment around oVirt preventing any issue (the version lock usage shows that it's already a concern oVirt's people are dealing with and I thank you. Keep strengthening.)


--

Nicolas ECARNOT