While restarting openvswitch "systemctl restart openvswitch", (restart is required after setting the DPDK_OPTIONS), on the compute node, the ovs user bridge "br-link" is loosing the IP. We have captured the logs [2], where restart is issued at line #103. Can you please let us know if we are missing any configuration in the deployment? Let us know if you need access to the TripleO environment.

neutron/openvswitch-agent.log - http://pastebin.test.redhat.com/439103
openvswitch/ovs-vswitchd.log - http://pastebin.test.redhat.com/439102

[1] https://github.com/krsacme/tht-dpdk/blob/rhosp10k3/nic-configs/computeovsdpdk.yaml
[2] http://pastebin.test.redhat.com/439097

Aaron Conole's comments (in mail):

Did you set the datapath type correctly?  I didn't see so in the logs,
but you'll need to issue:

   ovs-vsctl set bridge br-link datapath_type=netdev

since it contains a port called dpdk0.  I didn't see anything else that
stood out as being wrong.  If the above doesn't correct it (and I
suggest restarting the ovs and address acquisition software once making
that change to be sure), can you capture an sosreport?

Created attachment 1231990 [details]
sosreport of the compute node

[root@overcloud-compute-0 ~]# ovs-vsctl list bridge | egrep "name|datapath_type"
datapath_type       : netdev
name                : br-ex
datapath_type       : netdev
name                : br-int
datapath_type       : netdev
name                : br-tun
datapath_type       : netdev
name                : br-link

We find that the OVS bridge br-link loses the IP when openvswitch is restarted (after configuring the DPDK_OPTIONS).

As a workaround we either reboot the compute node or follow the below steps

1. ifup br-link
2. systemctl restart neutron-openvswitch-agent.

This issue is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1373085. Thanks Peng for pointing out. 

As per the discussion, if the openvswitch is restarted, then the service which is assigning IP to the ovs bridge also should be restarted, which in our case would be network.service.

We have manually restarted the network.service and found that the br-link gets the IP successfully. Now, we need to add this part of the deployment step to restart network.service when openvswitch is restarted.

The puppet manifest vswitch::dpdk is responsible for setting the DPDK_OPTIONS and restarting the openvswitch. Need to analyze on how to incorporate this dependency in the deployment.

Along with OvS2.6 migration, we are changing the flow of initializing DPDK, with which, we don't need the restart. Once we are ready with the list of changes, we will update the BZ.

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.

Hi,

After deployment br-link got IP addr

15: br-link: <BROADCAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 14:02:ec:7c:87:7c brd ff:ff:ff:ff:ff:ff
    inet 10.35.141.21/28 brd 10.35.141.31 scope global br-link
       valid_lft forever preferred_lft forever
    inet6 fe80::1602:ecff:fe7c:877c/64 scope link 
       valid_lft forever preferred_lft forever

I've verified this bug using template: 
https://code.engineering.redhat.com/gerrit/gitweb?p=nfv-qe.git;a=tree;f=heat-templates-configs/samples/ospd-11-vxlan-dpdk-single-port-ctlplane-bonding

Puddle:2017-04-24.2

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