<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 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 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">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 class="gmail_signature"><div>Kevin Benton</div></div>
</div>