Bug 2019457

Upstream PR: https://github.com/nmstate/nmstate/pull/1724

Hi Mingyu,

Please do pretest using copr repo of these PRs:

 * RHEL 8.4: https://github.com/nmstate/nmstate/pull/1738
 * RHEL 8.5: https://github.com/nmstate/nmstate/pull/1737
 * RHEL 8.6: https://github.com/nmstate/nmstate/pull/1724

This bug is requesting 8.4 zstream (RHEL 8.5 is also required so we don't have regression comparing to 8.4.z).

Working on it

Hi Radim,

Could you please tell me how to reach the state *BEFORE* you applied desiredState? Or before you applied the new state, please show me something like:

ip link
nmstatectl show br-ex,(and other ovs stuff)
nmcli con

If I understand correctly, in the *BEFORE* stage, all the ovs devices were uncontrolled by NetworkManager, right? Then it appears that there's no chance for nmstate to configure it, as nmstate now cannot deal with a runtime ovs bridge.
So I got confused that how you can successfully apply the new state...

Thank you!

Created attachment 1842977 [details]
nmstatectl files

Hello Mingyu Shi,

The state before applying the desiredState is a clean OCP installation after the process of migration to OVN Kubernetes:
https://docs.openshift.com/container-platform/4.9/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.html#nw-ovn-kubernetes-migration_migrate-from-openshift-sdn

The OVS components are created during this process and also are managed by NetworkManager

Tested on 8.6/8.5/8.4, take 8.4 as an example:

Tested with versions:
nmstate-1.0.5-0.20211119102720219917.pr1738.2.g8590e6d.el8.noarch
nispor-1.0.1-4.el8.x86_64
NetworkManager-1.30.0-13.el8_4.x86_64
openvswitch2.13-2.13.0-124.el8fdp.x86_64


nmcli con add type ovs-bridge con.interface-name br-ex
nmcli con add type ovs-port conn.interface-name br-ex master br-ex
nmcli con add type ovs-interface slave-type ovs-port conn.interface-name br-ex master br-ex ipv4.method manual ipv4.addresses 192.168.199.2/24 
nmcli con add type ovs-port conn.interface-name eno1 master br-ex
nmcli conn add type ethernet conn.interface eno1 master eno1
echo "interfaces:
- name: br-ex
  type: ovs-interface
  state: up
- name: eno1
  type: ethernet
  state: up
- name: br-ex
  type: ovs-bridge
  state: up
  bridge:
    options:
      fail-mode: ''
      mcast-snooping-enable: false
      rstp: false
      stp: false
    port:
    - name: br-ex
    - name: eno1
    - name: ovn-veth
  lldp:
    enabled: false
- name: cnv-veth
  type: veth
  state: up
  ipv4:
    enabled: false
    dhcp: false
  ipv6:
    enabled: false
    autoconf: false
    dhcp: false
  veth:
    peer: ovn-veth
- name: ovn-veth
  type: veth
  state: up
  ipv4:
    enabled: false
    dhcp: false
  ipv6:
    enabled: false
    autoconf: false
    dhcp: false
  veth:
    peer: cnv-veth" | nmstatectl set -

With older version of nmstate, the result:
[17:28:42@kvm-04-guest29 ~]0# ovs-vsctl show
4bb50d34-88d1-4dc8-86cb-b5f97d8d18c0
    Bridge br-ex
        Port ovs-port-ovn-veth
            Interface ovn-veth
                type: system
        Port ovs-port-eno1
            Interface eno1
                type: system
        Port ovs-port-br-ex
            Interface br-ex
                type: internal
    ovs_version: "2.13.5"

The result if using fixed version:
[18:58:10@kvm-04-guest29 ~]0# ovs-vsctl show
4bb50d34-88d1-4dc8-86cb-b5f97d8d18c0
    Bridge br-ex
        Port ovn-veth
            Interface ovn-veth
                type: system
        Port eno1
            Interface eno1
                type: system
        Port br-ex
            Interface br-ex
                type: internal
    ovs_version: "2.13.5"

Hi Radim,

It seems that the current fix only removes "PREFIX-" in the port name, it meets your scenario, but the root cause "changing names of existing ovs-bridge ports" still exists.
Does it OK for you?

Here's an example:
For testing, I manually prefixed "ovsport_" in port name:
[17:03:47@mshi860 ~]0# ovs-vsctl show
95ae970e-5943-488f-a63b-f9a07cf7a963
    Bridge br-ex
        Port ovsport_ovspatch0
            Interface ovspatch0
                type: patch
                options: {peer=ovspatch0_p}
        Port ovsport_veth0
            Interface veth0
                type: system
        Port ovsport_ovspatch0_p
            Interface ovspatch0_p
                type: patch
                options: {peer=ovspatch0}
        Port ovsport_br-ex
            Interface br-ex
                type: internal
    ovs_version: "2.13.5"

After applied the new state, the port name changed(it removed the prefix part "ovsport_"):
[17:04:02@mshi860 ~]0# ovs-vsctl show
95ae970e-5943-488f-a63b-f9a07cf7a963
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port veth0
            Interface veth0
                type: system
        Port ovspatch0_p
            Interface ovspatch0_p
                type: patch
                options: {peer=ovspatch0}
        Port ovspatch0
            Interface ovspatch0
                type: patch
                options: {peer=ovspatch0_p}
        Port ovn-veth
            Interface ovn-veth
                type: system
    ovs_version: "2.13.5"


nmstate-1.2.0-1.el8.x86_64
nispor-1.2.2-1.el8.x86_64
NetworkManager-1.36.0-0.3.el8.x86_64
openvswitch2.13-2.13.0-142.el8fdp.x86_64

Hello Mingyu,

Thanks for the heads up.
In our use-case, we're not using custom prefixes, so the current behaviour works for us.

But I see your point that the BZ desicription is not being completely honest.
Maybe we can change the title to 
"nmstate prefixes names of existing ovs-bridge ports with 'ovs-port-'" ? What do you think?


In the future, a new BZ may be opened to achieve name consistency for manually prefixed interfaces, if the need arises.

As https://bugzilla.redhat.com/show_bug.cgi?id=2019457#c13 shows, nmstate now uses same name on ovs bridge, port and interface.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nmstate bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:1772