Comment 8 for bug 1897863

Some notes wrt comment #7:

> Now, here in tripleo-ovs-upgrade, I'm not sure we have anything to fix
> as the non-layered to layered scenario should be covered. If not we
> will fix it. We cannot reach conclusion until we know if the new
> version of ovs has restart in postuninstall. We only know that the
> previous had it :)

I understand you mean the non-layered ovs, These are the uninstall scriptlets for the initially installed openvswitch-2.12.0:

preuninstall scriptlet (using /bin/sh):

if [ $1 -eq 0 ] ; then
        # Package removal, not upgrade
        systemctl --no-reload disable --now openvswitch.service &>/dev/null || :
fi
postuninstall program: /bin/sh

postuninstall is empty.

>> After this upgrade, openvswitch service is stopped, this is expected
>> and a design decision.

> I think at some point we should challenge that decision. This makes
> the upgrade of that package unusable in production environment. You
> upgrade your ovs, and, by design, it introduces a cut in your flows.
>
> We have lost days and days and a created a good deal of unhappy
> costumers because of that packaging decision.

I agree, I think this is related to the package renaming in FDP which was decided by that team, unrelated to RDO itself.

> It's easy to remove the conditional so that we always do the restart:
> but then we could miss cases of ovs upgrade not being treated
> specialy. Basically we would have never seen this issue. It's really
> being convenient vs being right choice here (i think). I believe being
> right should be favored, but maybe being conveniant/resiliant is
> better.

I think removing the conditional would not hurt as it's just make sure ovs is running but i understand we prefer to be aware if something is going in an unexpected path, so yes, i think it's good to keep it as is.

>> and also it seems it doesn't cover the upgrade from non-layered to
>> layered.

> So, we should support this case. I cannot reach any conclusion here
> because of the initial "ci yum upgrade", but it needs to be check.
>
> From reading the code, we go either in layered or not layered upgrade
> of ovs. We don't see the rdo-openvswitch layered product but we should
> see the non-layere product[1].
>
> Then we check if that version has restart in postuninstall to decide
> if we take action.

The upgrade should be:

openvswitch -> rdo-openvswitch + openvswitch2.13

I'd say this is not treated properly in the tripleo_ovs_upgrade.py. I've been doing some manual tests with a playbook which only runs that task and seems to not work (after replacing rhosp-openvswitch by rdo-openvswitch) in this case. I'd say it has some assumptions of upgrades non-layered to non-layered and layered to layered but not this case.