Open Stack

Hi,

----- On Aug 17, 2016, at 3:32 AM, James Denton james.denton at rackspace.com wrote:

> I don’t have the exact steps offhand, but you should be able to create a veth
> pair manually, attach one end to your existing bridge, and specify the other
> end in the bridge_mappings section. Make sure you set both ends up using ‘ip
> link set <dev> up’ prior to this. The veth pair will end up linking the bridges
> together.

That suggestion does indeed work (though it feels a bit dirty ;-)),

ip link add dev veth1 type veth peer name veth2
ip link set dev veth1 up
ip link set dev veth2 up

> Nova/Neutron should still handle putting the tap interface of the instance in
> the bridge, even if bridge_mappings is wrong or not working. The port’s device
> owner is compute:nova, which likely explains the message you saw in the log.

Which is strange, because the owner can't be set by the OS' interface-scripts creating the bridge (or nova tried to do the work before libvirt but that failed), but anyway,

> Hope that helps!

Thanks for the suggestion,

Paul


> James
> 
> 
> From: Paul Dekkers <paul.dekkers at surfnet.nl>
> Date: Tuesday, August 16, 2016 at 12:18 PM
> To: George Paraskevas <paraskgeor at gmail.com>, openstack-operators
> <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] neutron flat network on existing bridge fails
> 
> Hi,
> 
> Thanks for your suggestion - I don't think that's it, because that gives me:
> 
> Unable to add br224 to brqf709c220-fd! Exception: Exit code: 1; Stdin: ; Stdout:
> ; Stderr: device br224 is a bridge device itself; can't enslave a bridge device
> to a bridge device.
> 
> and
> 
> Skip adding device tapf99013c6-6b to brqf709c220-fd. It is owned by compute:nova
> and thus added elsewhere. _add_tap_interface
> /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:473
> 
> while this tapf99013c6-6b now actually is enslaved to brqf709c220-fd, even with
> the wrong physical_interface_mappings setting. So I guess it's ignored because
> of the error, or some other code built that bridge (nova? as it's owned by
> compute:nova ? I had no idea a bridge/interface could have an owner...)
> 
> Regards,
> Paul
> 
> 
> On 16-08-16 17:39, George Paraskevas wrote:
> 
> Hello,
> With Linux bridge, I believe you should use physical _interface_mappings
> =provider:br224
> Beat regards
> George
> 
> On Tue, 16 Aug 2016, 16:48 Paul Dekkers,
> <paul.dekkers at surfnet.nl<mailto:paul.dekkers at surfnet.nl>> wrote:
> Hi,
> 
> I'm using Ubuntu 16.04.1 with it's Mitaka release, and neutron flat
> networking with linuxbridge+ml2:
> 
> I'd like to attach my flat neutron network to an existing linuxbridge on
> my system. This fails with an error like:
> 
> 2016-08-16 15:07:00.711 7982 DEBUG
> neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent
> [req-720266dc-fe8d-47c4-a7df-19fee7a8d679 - - - - -] Skip adding device
> tapf99013c6-6b to br224. It is owned by compute:nova and thus added
> elsewhere. _add_tap_interface
> /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:473
> 
> with the result that the tap interface is added to a newly created
> bridge instead of the existing (br224) bridge.
> 
> I've set
> bridge_mappings = provider:br224
> in /etc/neutron/plugins/ml2/linuxbridge_agent.ini
> 
> (because if I use
> physical_interface_mappings = provider:vlan224
> the vlan224 interface is actually detached from the original bridge)
> 
> I've created the bridge via /etc/network/interfaces:
> 
> auto br224
> iface br224 inet manual
>        bridge_ports vlan224
> 
> auto vlan224
> iface vlan224 inet manual
>        vlan_raw_device eno1
> 
> Reason for doing this is that I'd like to attach an lxc container to
> this bridge (and only when neutron needs it the "brqf709c220-fd" (with
> for me an unpredictable name) is setup, so I can't use that), and/or
> like to have the machine itself use an interface on this network. (This
> is also my reason for using flat networking, and not vlan.)
> 
> I've created the neutron networks with
> 
> neutron net-create default --shared --provider:physical_network provider
> --provider:network_type flat
> 
> (I would repeat this with a different physical_network name if I need
> more VLANs, instead of using the --provider:segmentation_id.)
> 
> Instance networking works when I let nova/neutron create the bridge
> interfaces.
> 
> Any idea why neutron refuses to use the bridge_mappings and why it
> creates a new interface?
> 
> Regards,
> Paul
> 
> P.S. To me it feels like this is what people would need when setting up
> a small single-network setup (both for instances and OpenStack), but
> most examples use multiple networks anyway.
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators