<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body 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 class="moz-cite-prefix">On 05/09/2015 03:08 AM, Kevin Benton
wrote:<br>
</div>
<blockquote
cite="mid:CAO_F6JO4gz4-V7Kh+0+CRo3dXC11ecgUwZXccE6+BsUT7WV8wg@mail.gmail.com"
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 moz-do-not-send="true"
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 class="h5"><br>
<br>
On 05/08/2015 09:15 AM, Kevin Benton wrote:<br>
</div>
</div>
</div>
<div>
<div class="h5">
<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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org"
target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 class="gmail_signature">
<div>Kevin Benton</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>