Yes, that's result.
My plan was to allow 'internal' networks in neutron (by tenants itself),
but after some struggle we've decided to fallback to 'created by script
during tenant bootstrapping'.
Unfortunately, neutron has no conception of 'default physical segment'
for VLAN autoallocation for tenant networks (it just grabs first available).
On 05/09/2015 03:08 AM, Kevin Benton wrote:
So if you don't let tenants allocate networks, then why do the VLAN
ranges in neutron matter? It can just be part of your net-create scripts.
On Fri, May 8, 2015 at 9:35 AM, George Shuklin
<george.shuk...@gmail.com <mailto:george.shuk...@gmail.com>> wrote:
We've got a bunch of business logic above openstack. It's
allocating VLANs on-fly for external networks and connect pieces
outside neutron (configuring hardware router, etc).
Anyway, after some research we've decided to completely ditch idea
of 'tenant networks'. All networks are external and handled by our
software with administrative rights.
All networks for tenant are created during tenant bootstrap,
including local networks which are now looking funny 'external
local network without gateway'. By nailing every moving part in
'neutron net-create' we've got stable behaviour and kept
allocation database inside our software. That kills a huge part of
openstack idea, but at least it works straightforward and nice.
I really like to see all that been implemented in vendor plugins
for neutron, but average code and documentation quality for them
are below any usable level, so we implements hw configuration by
ourselves.
On 05/08/2015 09:15 AM, Kevin Benton wrote:
If one set of VLANs is for external networks which are created by
admins, why even specify network_vlan_ranges for that set?
For example, even if network_vlan_ranges is 'local:1000:4000',
you can still successfully run the following as an admin:
neutron net-create --provider:network_type=vlan
--provider:physical_network=local --provider:segmentation_id=40
myextnet --router:external
On Thu, May 7, 2015 at 7:32 AM, George Shuklin
<george.shuk...@gmail.com <mailto:george.shuk...@gmail.com>> wrote:
Hello everyone.
Got a problem: we want to use same physical interface for
external networks and virtual (tenant) networks. All inside
vlans with different ranges.
My expected config was:
[ml2]
type_drivers = vlan
tenant_network_types = vlan
[ml2_type_vlan]
network_vlan_ranges = external:1:100,local:1000:4000
[ovs]
bridge_mappings = external:br-ex,local:br-ex
But it does not work:
ERROR neutron.plugins.openvswitch.agent.ovs_neutron_agent [-]
Parsing bridge_mappings failed: Value br-ex in mapping:
'gp:br-ex' not unique. Agent terminated!
I understand that I can cheat and manually configure bridge
pile (br-ex and br-loc both plugged to br-real, which linked
to physical interface), but it looks very fragile.
Is any nicer way to do this? And why ml2 (ovs plugin?) does
not allow to use mapping from many networks to one bridge?
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Kevin Benton
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Kevin Benton
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
