A fix for this issue is in OSP 13 after the latest rebase to upstream stable/queens, but the rebase to stable/rocky for OSP 14 did not get it. We need to cherry-pick it so we don't introduce a regression. https://bugs.launchpad.net/neutron/+bug/1775146 https://review.openstack.org/#/c/604494/ https://code.engineering.redhat.com/gerrit/#/c/157017/ (already in progress)
Fix veerified: Ping works after ovs restart: 11:06:51 . /tmp/ir-venv-awm3Iep/bin/activate 11:06:51 infrared tripleo-undercloud -o undercloud_settings.yml --mirror tlv --version 14 --build 2018-12-13.3 --ssl false --tls-everywhere false 11:06:51 root@compute-2 heat-admin]# [root@compute-2 heat-admin]# [root@compute-2 heat-admin]# ps -ef | grep ovs 42435 30879 30860 0 13:12 ? 00:00:00 /bin/bash /neutron_ovs_agent_launcher.sh root 64679 30753 0 13:36 ? 00:00:00 /usr/bin/python2 /bin/privsep-helper --config-file /usr/share/nova/nova-dist.conf --config-file /etc/nova/nova.conf --privsep_context vif_plug_ovs.privsep.vif_plug --privsep_sock_path /tmp/tmpmjg90A/privsep.sock root 75578 72162 0 13:59 pts/2 00:00:00 grep --color=auto ovs [root@compute-2 heat-admin]# ps -ef | grep ovs 42435 30879 30860 0 13:12 ? 00:00:00 /bin/bash /neutron_ovs_agent_launcher.sh root 64679 30753 0 13:36 ? 00:00:00 /usr/bin/python2 /bin/privsep-helper --config-file /usr/share/nova/nova-dist.conf --config-file /etc/nova/nova.conf --privsep_context vif_plug_ovs.privsep.vif_plug --privsep_sock_path /tmp/tmpmjg90A/privsep.sock root 75590 72162 0 13:59 pts/2 00:00:00 grep --color=auto ovs [root@compute-2 heat-admin]# systemctl start ovs-vswitchd [root@compute-2 heat-admin]# virsh console 1 Connected to domain instance-00000002 Escape character is ^] $ $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:9f:03:bf brd ff:ff:ff:ff:ff:ff inet 10.1.0.15/24 brd 10.1.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe9f:3bf/64 scope link valid_lft forever preferred_lft forever $ ping 10.1.0.14 PING 10.1.0.14 (10.1.0.14): 56 data bytes 64 bytes from 10.1.0.14: seq=0 ttl=64 time=2.434 ms 64 bytes from 10.1.0.14: seq=1 ttl=64 time=0.628 ms 64 bytes from 10.1.0.14: seq=2 ttl=64 time=0.799 ms 64 bytes from 10.1.0.14: seq=3 ttl=64 time=0.841 ms 64 bytes from 10.1.0.14: seq=4 ttl=64 time=0.817 ms 64 bytes from 10.1.0.14: seq=5 ttl=64 time=0.626 ms ^C --- 10.1.0.14 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 0.626/1.024/2.434 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/RHEA-2019:0045