Flat network type seems broken on un-containerized compute nodes about ansible-lxc-rpc HOT 6 CLOSED

I ran into this last week and moved br-vlan to an unbridged interface. I'm working through a build with a flat network right now, I'll provide more information [when,if] I encounter it again.

-Alex

from ansible-lxc-rpc.

This is definitely a problem, I can totally see it now that it's come up. Neutron will refuse to bridge bridges, as the error message indicates, and for is_metal boxen (compute nodes) where we're not using containers, we're making use of the container_bridge key for networks instead of container_interface because we didn't account for interfaces like eth11 not existing on compute nodes.

On network nodes, an eth11 would be created by default inside of the neutron-agents container, but this obviously won't happen for us on compute nodes, since nova-compute is no longer containerized. Seems like the simplest solution is to change up the example interfaces file to create a veth pair with the appropriate name to emulate the containerization process.

For instance:

auto br-vlan
iface br-vlan inet manual
    # Create veth pair, don't bomb if already exists
    pre-up ip link add br-vlan-veth type veth peer name eth11 || true
    # Set both ends UP
    pre-up ip link set br-vlan-veth up
    pre-up ip link set eth11 up
    # Set bridge UP/DOWN
    up ip link set $IFACE up
    down ip link set $IFACE down
    # Delete veth pair on DOWN
    post-down ip link del br-vlan-veth || true
    # Add bond1 trunk and one veth end to bridge
    bridge_ports bond1 br-vlan-veth

Theory here being we create a veth pair with a unique name based on the bridge it's going in, and the other end is the same name it would have if it were in a container, so we just need to make sure the ml2_conf.ini mappings on compute nodes aren't doing anything different than non-compute nodes.

from ansible-lxc-rpc.

@cloudnull
Kevin, what were you doing here when this error came up? I haven't been able to reproduce. The neutron linuxbridge agent on the compute host doesn't ever try to add the br-vlan bridge to a brqXXXX bridge on my build. VM traffic is only sent through the br-vxlan interface.

-Alex

from ansible-lxc-rpc.

@ELEXTRO This would be expected when creating a flat type neutron network, like so:

neutron net-create --provider:network_type=flat --provider:physical_network=vlan flat-net1

The vlan network name is mapped in the ml2_conf.ini to the br-vlan bridge on compute nodes, but to eth11 in neutron-agents containers, as I mentioned in my comment above. This results in neutron trying to create a linux bridge and putting the mapped interface inside of it -- namely, the br-vlan bridge. This is when it fails.

In your build, it sounds like you're only creating VXLAN type networks, which will create a vxlan interface "based on" the mapped interface (where the mapping is named vxlan in neutron), which doesn't require bridging an interface directly -- instead it's indirectly "attached" to an interface, which can be a bridge interface, such as br-vxlan. Then, neutron adds this new vxlan interface to the brqXXXX bridge it creates, and there's no problem with it operating this way.

Likewise, with VLAN-type networks, neutron creates a VLAN-tagged interface, again, based on the mapped interface (br-vlan), and then the brqXXXX bridges this new tagged interface, and again there's no problem.

from ansible-lxc-rpc.

@Apsu

I created the flat network and implemented emulated containerization with the veth pairs as stated above, everything seems to be running as expected. Eth11 gets added to the linux bridge without throwing an error. You guys just have to make sure ml2_conf.ini is the same for compute hosts and the neutron agent containers if you decide to go this way.

-Alex

from ansible-lxc-rpc.

What happened to this issue?

from ansible-lxc-rpc.