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
