<p dir="ltr">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? </p>
<p dir="ltr">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? </p>
<p dir="ltr">Thanks, <br>
Kevin Benton </p>
<div class="gmail_quote">On May 9, 2015 17:16, "George Shuklin" <<a href="mailto:george.shuklin@gmail.com">george.shuklin@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Yes, that's result.<br>
<br>
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'.<br>
<br>
Unfortunately, neutron has no conception of 'default physical
segment' for VLAN autoallocation for tenant networks (it just grabs
first available).<br>
<br>
<div>On 05/09/2015 03:08 AM, Kevin Benton
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 8, 2015 at 9:35 AM, George
Shuklin <span dir="ltr"><<a href="mailto:george.shuklin@gmail.com" target="_blank">george.shuklin@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.
<div>
<div><br>
<br>
On 05/08/2015 09:15 AM, Kevin Benton wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">If one set of VLANs is for external
networks which are created by admins, why even
specify network_vlan_ranges for that set?
<div><br>
</div>
<div>For example, even if network_vlan_ranges is
'local:1000:4000', you can still successfully
run the following as an admin:</div>
<div>neutron net-create
--provider:network_type=vlan
--provider:physical_network=local
--provider:segmentation_id=40 myextnet
--router:external<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, May 7, 2015 at
7:32 AM, George Shuklin <span dir="ltr"><<a href="mailto:george.shuklin@gmail.com" target="_blank">george.shuklin@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone.<br>
<br>
Got a problem: we want to use same physical
interface for external networks and virtual
(tenant) networks. All inside vlans with
different ranges.<br>
<br>
My expected config was:<br>
<br>
[ml2]<br>
type_drivers = vlan<br>
tenant_network_types = vlan<br>
[ml2_type_vlan]<br>
network_vlan_ranges =
external:1:100,local:1000:4000<br>
[ovs]<br>
bridge_mappings = external:br-ex,local:br-ex<br>
<br>
But it does not work:<br>
<br>
ERROR
neutron.plugins.openvswitch.agent.ovs_neutron_agent
[-] Parsing bridge_mappings failed: Value
br-ex in mapping: 'gp:br-ex' not unique. Agent
terminated!<br>
<br>
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.<br>
<br>
Is any nicer way to do this? And why ml2 (ovs
plugin?) does not allow to use mapping from
many networks to one bridge?<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div>Kevin Benton</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div>Kevin Benton</div>
</div>
</div>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div>