On 05/11/2015 11:23 AM, Kevin Benton wrote:
I apologize but I didn't quite follow what the issue was with tenants
allocating networks in your use case, can you elaborate a bit there?
From what it sounded like, it seems like you could define the vlan
range you want the tenants' internal networks to come from in the
network_vlan_ranges. Then any admin networks would just specify the
segmentation id outside of that range. Why doesn't that work?
I (as admin) can use vlans outside of network_vlan_ranges in
[ml2_type_vlan] section of ml2_conf.ini?
I've never tried...
Yes, I can!
Thank you.
Thanks,
Kevin Benton
On May 9, 2015 17:16, "George Shuklin" <george.shuk...@gmail.com
<mailto:george.shuk...@gmail.com>> wrote:
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
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
