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? Thanks, Kevin Benton On May 9, 2015 17:16, "George Shuklin" <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> > 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> >> 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 >>> 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 >> >> > > > -- > Kevin Benton > > > > _______________________________________________ > OpenStack-operators mailing list > 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