Le 06/02/2019 à 15:42, Greg Sheremeta a écrit :
On Wed, Feb 6, 2019 at 6:33 AM Nicolas Ecarnot
<nicolas(a)ecarnot.net
<mailto: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...
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(a)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