+++ This bug was initially created as a clone of Bug #1779121 +++ Description of problem: In case the incremental processing code in ovn-controller hits a bug and the state is inconsistent there's no way to trigger a full recompute that would properly install all flows. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. ovn-appctl -t ovn-controller recompute 2. 3. Actual results: Command doesn't exist. Expected results: The command should run and force a full recompute in ovn-controller. Additional info:
Verified on ovn2.11.1-24： server: [root@dell-per740-12 bz1779124]# rpm -qa | grep -E "openvswitch|ovn" ovn2.11-central-2.11.1-24.el8fdp.x86_64 ovn2.11-2.11.1-24.el8fdp.x86_64 openvswitch2.11-2.11.0-35.el8fdp.x86_64 ovn2.11-host-2.11.1-24.el8fdp.x86_64 openvswitch-selinux-extra-policy-1.0-19.el8fdp.noarch [root@dell-per740-12 bz1779124]# cat setup.sh #!/bin/bash systemctl start openvswitch systemctl start ovn-northd ovn-nbctl set-connection ptcp:6641 ovn-sbctl set-connection ptcp:6642 ovs-vsctl set open . external_ids:system-id=hv1 external_ids:ovn-remote=tcp:20.0.30.25:6642 external_ids:ovn-encap-type=geneve external_ids:ovn-encap-ip=20.0.30.25 systemctl restart ovn-controller ip netns add server0 ip link add veth0_s0 netns server0 type veth peer name veth0_s0_p ip netns exec server0 ip link set lo up ip netns exec server0 ip link set veth0_s0 up ip netns exec server0 ip link set veth0_s0 address 00:00:00:01:01:02 ip netns exec server0 ip addr add 192.168.1.1/24 dev veth0_s0 ovs-vsctl add-port br-int veth0_s0_p ip link set veth0_s0_p up ovs-vsctl set interface veth0_s0_p external_ids:iface-id=ls1p1 ovn-nbctl ls-add ls1 ovn-nbctl lsp-add ls1 ls1p1 ovn-nbctl lsp-set-addresses ls1p1 00:00:00:01:01:02 ovn-nbctl lsp-add ls1 ls1p2 ovn-nbctl lsp-set-addresses ls1p2 00:00:00:01:02:02 client: [root@hp-dl380pg8-12 bz1779124]# rpm -qa | grep -E "openvswitch|ovn" openvswitch2.11-2.11.0-35.el7fdp.x86_64 ovn2.11-2.11.1-24.el7fdp.x86_64 openvswitch-selinux-extra-policy-1.0-14.el7fdp.noarch ovn2.11-host-2.11.1-24.el7fdp.x86_64 ovn2.11-central-2.11.1-24.el7fdp.x86_64 [root@hp-dl380pg8-12 bz1779124]# cat setup.sh #!/bin/bash systemctl start openvswitch ovs-vsctl set open . external_ids:system-id=hv0 external_ids:ovn-remote=tcp:20.0.30.25:6642 external_ids:ovn-encap-type=geneve external_ids:ovn-encap-ip=20.0.30.26 systemctl restart ovn-controller ip netns add client0 ip link add veth0_c0 netns client0 type veth peer name veth0_c0_p ip netns exec client0 ip link set lo up ip netns exec client0 ip link set veth0_c0 up ip netns exec client0 ip link set veth0_c0 address 00:00:00:01:02:02 ip netns exec client0 ip addr add 192.168.1.2/24 dev veth0_c0 ovs-vsctl add-port br-int veth0_c0_p ip link set veth0_c0_p up ovs-vsctl set interface veth0_c0_p external_ids:iface-id=ls1p2 recompute on server: [root@hp-dl380pg8-12 bz1779124]# ovs-appctl -t ovn-controller recompute [root@hp-dl380pg8-12 bz1779124]# ip netns exec client0 ping 192.168.1.1 -c 5 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.31 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.212 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.184 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.202 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.190 ms recompute on client: [root@hp-dl380pg8-12 bz1779124]# ovs-appctl -t ovn-controller recompute [root@hp-dl380pg8-12 bz1779124]# ip netns exec client0 ping 192.168.1.1 -c 5 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.31 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.212 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.184 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.202 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.190 ms --- 192.168.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 0.184/0.421/1.318/0.448 ms
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, 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/RHBA-2020:0190