Comment 12 for bug 1940844

Hi,

I'm not convinced it should be in upgrade code as standalone upgrade doesn't include any reboot of the "controller" which should happen during a normal upgrade.

Here we can see that ovs get special treatment during upgrade and hence is not restarted:

I that log : https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_80f/807057/1/check/tripleo-ci-centos-8-standalone-upgrade-ussuri/80fa688/logs/undercloud/var/log/dnf.rpm.log

we have the installation of ovs (I guess that the train version):

2021-09-03T10:19:04+0000 SUBDEBUG Installed: network-scripts-10.00.15-1.el8.x86_64
2021-09-03T10:19:04+0000 SUBDEBUG Installed: network-scripts-openvswitch-2.12.0-1.1.el8.x86_64
2021-09-03T10:19:04+0000 SUBDEBUG Installed: openvswitch-2.12.0-1.1.el8.x86_64
2021-09-03T10:19:05+0000 SUBDEBUG Installed: rdo-openvswitch-2.12-1.el8.noarch

then the upgrade of ovs

2021-09-03T11:22:30+0000 SUBDEBUG Installed: openvswitch-selinux-extra-policy-1.0-28.el8.noarch
2021-09-03T11:23:07+0000 SUBDEBUG Installed: openvswitch2.13-2.13.0-122.el8.x86_64
2021-09-03T11:23:09+0000 SUBDEBUG Upgrade: rdo-openvswitch-1:2.13-3.el8.noarch
2021-09-03T11:23:09+0000 SUBDEBUG Upgraded: rdo-openvswitch-2.12-1.el8.noarch

which happens during the special treatment of ovs, hence it's certainly not restarted:

https://zuul.opendev.org/t/openstack/build/80fa688140e9461ba7094c558da6549f/log/logs/undercloud/home/zuul/standalone_upgrade.log?severity=0#1960-1962

2021-09-03 11:22:22 | 2021-09-03 11:22:22.604074 | fa163ece-c078-d86c-8770-000000000669 | TIMING | Set leapp facts | standalone | 0:02:41.006733 | 0.04s
2021-09-03 11:22:22 | 2021-09-03 11:22:22.631304 | fa163ece-c078-d86c-8770-00000000066a | TASK | Special treatment for OpenvSwitch
2021-09-03 11:23:13 | 2021-09-03 11:23:13.866375 | fa163ece-c078-d86c-8770-00000000066a | CHANGED | Special treatment for OpenvSwitch | standalone
2021-09-03 11:23:13 | 2021-09-03 11:23:13.868822 | fa163ece-c078-d86c-8770-00000000066a | TIMING | Special treatment for OpenvSwitch | standalone | 0:03:32.271480 | 51.24s

Then we have ovn container upgraded so at that point:

 - ovn is alive with ussuri version
 - ovs is still at train version

I think it's safe to have the ci job restarting ovs:

 - ussuri upgrade path from train does have node rebooted during the upgrade, so the restart of ovs would happen;
 - catching train/ussuri incompatibility in ovn/ovs may not be relevant at all for the standalone upgrade: this is open for debate, but it seems to me that incompatibility could happen here;
 - modifying the upgrade for the ussuri standalone upgrade path doesn't feel right as:
   - it doesn't exist downstream: hence this change will get very little coverage;