Our Nic config for OVS-DPDK in a) Compute node. - type: ovs_user_bridge name: br-link use_dhcp: false addresses: - ip_netmask: {get_param: TenantIpSubnet} members: - type: ovs_dpdk_port name: dpdk0 members: - type: interface name: nic4 b) Controller node - type: ovs_bridge name: br-link use_dhcp: false addresses: - ip_netmask: {get_param: TenantIpSubnet} members: - type: interface name: nic4 The PING test fails (/usr/share/openstack-tripleo-heat-templates/validation-scripts/all-nodes.sh) after first boot during deployment. The DPDK params are not set and at this stage, the DPDK interface is in error state and br-link will not have the IP Address, which causes the PING test to fail. Please note that the DPDK interface will be up only after setting the DPDK OPTIONS in /etc/sysconfig/openvswitch (during step 4 of deployment) and restarting the openvswitch.service (in post-install scripts). If we comment the ping test, then the deployment succeeds.
Dan Sneddon's Comments: It sounds like we will need some modifications to make this work, I think any of the following would work: * Reorder operations so that the DPDK initialization happens before the ping test, perhaps by moving the setting of /etc/sysconfig/openvswitch and restarting of the openvswitch service to an earlier step in the deployment * Modify the ping test so that it ignores interfaces on DPDK bridges * Modify os-net-config so that it completes all the actions needed to make the interface pingable after os-net-config runs
This scenario can be validated by QA by the document provided by karthik. https://docs.google.com/a/redhat.com/document/d/1VhpoBcKj5oVZqXUoDPUKh_g43ITUazZcSl-GiJOxYUs/edit?usp=sharing. Request the QE team to talk to Karthik before testing this scenario to be in sync with the document.
Thank you Karthik, I've verified this bug with OSPd 11, puddle 2017-04-24.2 br-link gets an IP and passes PING test. Thanks,
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-2017:1245