Hi, ----- On Aug 17, 2016, at 3:32 AM, James Denton [email protected] 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 <[email protected]> > Date: Tuesday, August 16, 2016 at 12:18 PM > To: George Paraskevas <[email protected]>, openstack-operators > <[email protected]> > 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, > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
