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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
