-
Bug
-
Resolution: Done
-
Blocker
-
rhos-18.0.0
-
8
-
False
-
-
False
-
Proposed
-
No Docs Impact
-
ansible-collection-containers-podman-1.9.4-3.el9ost
-
Proposed
-
Proposed
-
None
-
Release Note Not Required
-
-
-
-
Approved
-
8
-
Important
Both during adoption and later during updates/upgrades of the EDPM nodes we should make sure that openvswitch package update won't disrupt the dataplane traffic.
In TripleO it was done with hack https://github.com/openstack-archive/tripleo-heat-templates/blob/stable/wallaby/deployment/undercloud/undercloud-upgrade.yaml#L126-L145 and on overclouds https://github.com/openstack-archive/tripleo-heat-templates/blob/stable/wallaby/deployment/tripleo-packages/tripleo-packages-baremetal-puppet.yaml#L468-L515 The hack was effectively skipping some parts of rpm installation for the package.
Right now in the OSP 18, after https://github.com/openstack-k8s-operators/edpm-ansible/pull/539 was merged we don't run update packages for update/upgrades but that may change in future.
As per OVS folks, the right way to update vswitchd is to use flow-restore-wait option in db to affect how vswitchd restarts; then store / restore flows using ovs-ofctl; then disable the option. These steps can be orchestrated in ansible.
Note: a similar problem also applies to podified OVS. There, RPM hack definitely doesn't apply, so it would be wise to come up with some common solution to both scenarios.
Note: this bug is only about EDPM node side. Podified OVS handling of OVS image updates should be tracked in a separate bug (to be reported.)
- causes
-
OSPRH-6505 Adoption from ifcfg to nmstate provider in os-net-config for EDPM nodes
- Refinement
- incorporates
-
OSPRH-4385 Ensure we can perform minor updates of Neutron components without impacting workload (connection drops, packets lost)
- Closed
- is related to
-
OSPRH-6326 Update ovs container image without disrupting gateway datapath
- Verified
- relates to
-
FDP-568 OVN: Implement ND without controller action
- New
- links to
- mentioned on