On Thu, Jul 30, 2020 at 10:57 AM Yedidyah Bar David <didi@redhat.com> wrote:

On Thu, Jul 30, 2020 at 10:47 AM Alex K <rightkicktech@gmail.com> wrote:
>
>
>
> On Thu, Jul 30, 2020 at 10:25 AM Alex K <rightkicktech@gmail.com> wrote:
>>
>> Hi all!
>>
>> I am going though an upgrade from ovirt 4.2 (4.2.8.2-1.el7) to 4.3 for a two node cluster with self hosted engine. I have done previously upgrades from 4.1 to 4.2 successfully with minor issues which where fixed.
>>
>> I wanted to confirm with you, in case I am missing anything that may have changed in the mean time, on the steps for minor and major upgrade:
>>
>> # Ovirt procedure for minor upgrade: (4.x.y -> 4.x.z)
>> • enable global maintenance mode
>> • at engine: engine-upgrade-check
>> • at engine: yum update "ovirt-*-setup*"
>> • at engine: engine-setup
>> • at engine: yum update

stop global maintenance

>> • at each host from GUI: host -> installation -> upgrade
>> • at each host: yum update, reboot, activate
>>
>> # Ovirt procedure for major upgrade (4.x -> 4.y)
>> • update DC to latest minor version (engine + nodes)
>> • enable global maintenance
>> • at engine: install major version repo: yum install https://resources.ovirt.org/pub/yum-repo/ovirt-release4x.rpm
>> • at engine: engine-upgrade-check
>> • at engine:  yum update "ovirt-*-setup*"
>> • at engine: engine-setup
>> • at engine: remove the old ovirt release from /etc/yum.repos.d
>> • at engine: yum update
>> • after completion of engine upgrade disable global maintenance
>> • verify engine version
>> • update each host/node: update to minor, then install new repo, remove old repo, yum update, reboot, activate
>> • after completion of updates: set DC and cluster compatibility level to latest version 4.x.
>> • shutdown guest VMs and confirm they start up again. (you may need to disable guest disk leases or re-activate guest disks)
>> • check events for any issues and fix accordingly
>>
>> Am I missing anything? I am planning the upgrade hoping to have no issues since the cluster is hosting production VMs.
>
> Also I am concerned about the minor release upgrade for any package conflicts due to CentOS repos (I have not managed yet to simulate this in a virtual environment). The hosts/nodes are CentOS Linux release 7.6.1810 (Core). Do I have to lock the repos to a specific centos version to avoid possible issues (I am afraid CentOS upgrading to latest 7 and causing dependency issues with 4.2 - I was not able to find out the latest CentOS 7 versino compatible with 4.2).

You are right in that this can be a problem.
Generally speaking, your best bet is to find out which CentOS 7 was
latest when 4.3 was released (or shortly before that) - that's likely
the most reliable version for 4.2. Shortly after 4.3 was released, we
stopped checking 4.2 with newer CentOS, so things indeed might have
broken without anyone noticing.

OK. I will try to figure this out. 

What do you mean in "I have not managed yet to simulate this in a
virtual environment"? That it fails? Passes? Didn't try yet?

Did not manage to yet test it and find out. In the process of doing so.  I recall several dependency issues when going from 4.1 to 4.2. Unfortunately I am not able to keep up with the ovirt upgrades in a timely manner (currently managing around 20 such clusters) hence have to face the issues when I manage to do the upgrades... :) I will have to further streamline the process perhaps through ansible and see if I can at least keep a local repo for such delayed upgrades.

I'd
definitely first simulate this in a test (can be virtual) env, before
production. If possible, I'd start with a copy of production - and
make sure it's an isolated network, so that the tested engine can't
mess with your production hosts.

Good luck and best regards,

Thank you Didi

--
Didi