Bug 1469839

Created attachment 1297686 [details]
my templates

I just realized that the template format between OSP 10 and OSP 11 changed. OSP 10 by default still uses OS::Heat::StructuredConfig - may this be the issue, and may I need to use something similar to:
{get_param: MTU}
{get_param: DEVICE}
instead? However, these are obviously not in the parameter list, so some other modification may be needed ...

Karthik, thanks, this was a code 18.

With fixed templates:
            -
              type: ovs_user_bridge
              name: br-link
              use_dhcp: false
              members:
                -
                  type: ovs_dpdk_port
                  name: dpdk0
                  mtu: 2000
                  ovs_extra:
                    - set interface $DEVICE mtu_request=$MTU
                  members:
                    -
                      type: interface
                      name: enp181s0
                      # name: enp201s0

This works:

[root@overcloud-compute-0 ~]# ovs-vsctl show
8a9a2a4c-e75d-45b2-87eb-6388fd79fe0c
    Manager "ptcp:6640:127.0.0.1"
        is_connected: true
    Bridge br-link
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-link
            Interface phy-br-link
                type: patch
                options: {peer=int-br-link}
        Port br-link
            Interface br-link
                type: internal
        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
    Bridge br-int
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
        Port int-br-link
            Interface int-br-link
                type: patch
                options: {peer=phy-br-link}
    ovs_version: "2.6.1"
[root@overcloud-compute-0 ~]# ovs-vsctl list interface dpdk0 | grep mtu
mtu                 : 2000
mtu_request         : 2000


Please go ahead and close this.

For the benefit of the wider audience: Adding Jim/Vincent from the sprint team to this BZ.

When this BZ was listed in the RHOS-PRIO, we made these statements:
For the benefit of the wider audience:
A. We would need the os-vif back port from compute DFG, this would enable the MTU setting on the vhost-user ports (Guest VM) for the end to end feature completion.
Compute DFG is aware of this backporting effort and their target to get this done for 10z4 (updated in the BZ):


B. We need an answer from Sprint folks to the above question, this would clarify that we at the NFV DFG would have to backport the os-net-config  change.
We discussed this at the DFG and in the sprint call to see if the above manual change was okay and we can move on. We havent heard back from the sprint account team as mentioned.
Any way We've targeted this backport for our 10z4 release.

C. In the sprint call, i volunteered to write these steps and provide end-to-end DEV testing is done post A&B, for the benefit of the sprint consultant.
Similar to https://bugzilla.redhat.com/show_bug.cgi?id=1457384#c7. 

This particular BZ tracks (B) & (C) and as Andreas mentions this is taken care. (A) is still pending. 
This BZ is primarily opened for (B) && (C) hence closing it as suggested.