Open Stack

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?

Thanks,
Kevin Benton
On May 9, 2015 17:16, "George Shuklin" <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>
> 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>
>> 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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>>
>>  --
>>  Kevin Benton
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> 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
> 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/20150511/a5f2ae9e/attachment.html>