Sure, but at date of announce of oVirt 4.3.5 (30/07), CentOS 7.7 was not available yet (17/09)... so that phrase was a bit speculation... ;-)

In my case I currently have both my separate server engine and 3 plain hosts in CentOS 7.6 + 4.3.5

What would it be the workflow?

Did you test this scenario, that I think will be very common with users that upgrades often (eg in their test env)?

engine

1) yum update to update OS

I think versionlock plugin of oVirt will prevent update of its core parts, correct?

I see many ovirt related packages put in. See here:

versionlock prevented:

[g.cecchi@ovmgr1 ~]$ sudo yum versionlock status
Loaded plugins: fastestmirror, langpacks, versionlock
Repository centos-sclo-rh-release is listed more than once in the configuration
Loading mirror speeds from cached hostfile
 * base: centos.mirror.garr.it
 * epel-util: epel.besthosting.ua
 * extras: centos.mirror.garr.it
 * ovirt-4.3: ftp.nluug.nl
 * ovirt-4.3-epel: epel.besthosting.ua
 * updates: centos.mirror.garr.it
0:ovirt-engine-webadmin-portal-4.3.6.6-1.el7.*
0:ovirt-engine-ui-extensions-1.0.10-1.el7.*
0:ovirt-engine-dwh-4.3.6-1.el7.*
0:ovirt-engine-tools-backup-4.3.6.6-1.el7.*
0:ovirt-engine-restapi-4.3.6.6-1.el7.*
0:ovirt-engine-dbscripts-4.3.6.6-1.el7.*
0:ovirt-engine-4.3.6.6-1.el7.*
0:ovirt-engine-backend-4.3.6.6-1.el7.*
0:ovirt-engine-wildfly-17.0.1-1.el7.*
0:ovirt-engine-wildfly-overlay-17.0.1-1.el7.*
0:ovirt-engine-tools-4.3.6.6-1.el7.*
versionlock status done
[g.cecchi@ovmgr1 ~]$ 

2) reboot

3) update oVirt

NOTE: probably non need d update setup packages, because put in in previous update phase, correct? 

4) eventually yum update again to see if any packages due to new repo conf 

5) reboot of engine

hosts

6) put into maintenance

7) simply yum update that will update CentOS packages + oVirt ones (vdsm and such..)

Do you agree or have alternative path?

Thanks,

Gianluca