Open Stack

On 05/11/2015 11:23 AM, Kevin Benton wrote:
>
> 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?
>

I (as admin) can use vlans outside of network_vlan_ranges in 
[ml2_type_vlan] section of ml2_conf.ini?

I've never tried...

Yes, I can!

Thank you.
>
> Thanks,
> Kevin Benton
>
> On May 9, 2015 17:16, "George Shuklin" <george.shuklin at gmail.com 
> <mailto:george.shuklin at 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.shuklin at gmail.com <mailto:george.shuklin at 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.shuklin at gmail.com <mailto:george.shuklin at 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 at lists.openstack.org
>>>             <mailto:OpenStack-operators at lists.openstack.org>
>>>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Kevin Benton
>>
>>
>>         _______________________________________________
>>         OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>>     -- 
>>     Kevin Benton
>
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150514/d1eaf50c/attachment.html>