So, looking at the yaml, I see several spots where both vlxan and gee are listed, these look to me to be the most relevant:

key: ovs_tunnel_types
        role: HA Controller
        puppetclass: quickstack::pacemaker::neutron
        value: ! '["vxlan","gre"]'

and

key: ovs_tunnel_types
        role: Compute (Neutron)
        puppetclass: quickstack::neutron::compute
        value: ! '["vxlan","gre"]'

I see the segmentation param is already set to 'vxlan', so I suspect staypuft just needs to update how they are populating the above two fields, moving there so they can loo at it.

(In reply to Jason Guiditta from comment #2)
> So, looking at the yaml, I see several spots where both vlxan and gee are
Darn autocorrect, s/gee/gre
> listed, these look to me to be the most relevant:
> 
> key: ovs_tunnel_types
>         role: HA Controller
>         puppetclass: quickstack::pacemaker::neutron
>         value: ! '["vxlan","gre"]'
> 
> and
> 
> key: ovs_tunnel_types
>         role: Compute (Neutron)
>         puppetclass: quickstack::neutron::compute
>         value: ! '["vxlan","gre"]'
> 
> I see the segmentation param is already set to 'vxlan', so I suspect
> staypuft just needs to update how they are populating the above two fields,
> moving there so they can loo at it.

neutron shall not create any tunnels unless there are VXLAN or GRE networks tenant networks.


Leonid, did you create any tenant networks with gre?

That's allowed with the current configuration (mixed GRE & VXLAN). But the tunnels should only come up in it's flavours if you create specific GRE or VXLAN segmentation networks for tenants.

If that's not the case,

One fix could be limiting to only "gre" or only "vxlan" on all the configuratioms when we chose one.

Fresh install, no tenants created yet : 

[root@mac00265535005c ~]# ovs-vsctl show
75bd1ef8-f100-48bd-bdf9-4605a8ba62fc
    Bridge br-int
        fail_mode: secure
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        Port "vxlan-c0a8fe16"
            Interface "vxlan-c0a8fe16"
                type: vxlan
                options: {in_key=flow, local_ip="192.168.254.19", out_key=flow, remote_ip="192.168.254.22"}
        Port "vxlan-c0a8fe15"
            Interface "vxlan-c0a8fe15"
                type: vxlan
                options: {in_key=flow, local_ip="192.168.254.19", out_key=flow, remote_ip="192.168.254.21"}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-c0a8fe14"
            Interface "vxlan-c0a8fe14"
                type: vxlan
                options: {in_key=flow, local_ip="192.168.254.19", out_key=flow, remote_ip="192.168.254.20"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-c0a8fe15"
            Interface "gre-c0a8fe15"
                type: gre
                options: {in_key=flow, local_ip="192.168.254.19", out_key=flow, remote_ip="192.168.254.21"}
        Port "gre-c0a8fe16"
            Interface "gre-c0a8fe16"
                type: gre
                options: {in_key=flow, local_ip="192.168.254.19", out_key=flow, remote_ip="192.168.254.22"}
        Port "gre-c0a8fe14"
            Interface "gre-c0a8fe14"
                type: gre
                options: {in_key=flow, local_ip="192.168.254.19", out_key=flow, remote_ip="192.168.254.20"}
    ovs_version: "2.1.3"

It was a fresh install. no tenants were created.

Leonid,

Do you happen to have any puppet logs from the node available? Is this still reproducible? Limiting ovs_tunnel_types to just the tenant network type chosen by the user may help this, but it may not be sufficient, depending on exactly why the extra tunnel is being created.

PR is: https://github.com/theforeman/staypuft/pull/305

This limits ovs_tunnel_types to the selected tenant type.

ruby193-rubygem-staypuft-0.3.5-1.el6ost.noarch

[root@macf04da2732fb1 ~]# ovs-vsctl show
c415c9b3-25bb-43a5-9b38-07d306033727
    Bridge br-tun
        Port "vxlan-0a23a0a9"
            Interface "vxlan-0a23a0a9"
                type: vxlan
                options: {in_key=flow, local_ip="10.35.160.173", out_key=flow, remote_ip="10.35.160.169"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-0a23a0ab"
            Interface "vxlan-0a23a0ab"
                type: vxlan
                options: {in_key=flow, local_ip="10.35.160.173", out_key=flow, remote_ip="10.35.160.171"}
    Bridge br-int
        fail_mode: secure
        Port int-br-ex
            Interface int-br-ex
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port "enp3s0f1"
            Interface "enp3s0f1"
    ovs_version: "2.1.3"
[root@macf04da2732fb1 ~]#

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.

http://rhn.redhat.com/errata/RHBA-2014-1350.html