[openstack-dev] [neutron]The mechanism of physical_network & segmentation_id is logical?

黎林果 lilinguo8212 at gmail.com
Tue Feb 25 03:54:04 UTC 2014


Yes. You are right.

The bp has implemented this function.

Thank you very much.

2014-02-25 11:01 GMT+08:00 Robert Kukura <rkukura at redhat.com>:
> On 02/24/2014 09:11 PM, 黎林果 wrote:
>> Bob,
>>
>> Thank you very much. I have understood.
>>
>> Another question:
>> When create network with provider, if the network type is VLAN, the
>> provider:segmentation_id must be specified.
>>
>> In function: def _process_provider_create(self, context, attrs)
>>
>> I think it can come from the db too. If get from db failed, then throw
>> exception.
>
> I think you are suggesting that if the provider:network_type and
> provider:physical_network are specified, but provider:segmentation_id is
> not specified, then a value should be allocated from the tenant network
> pool. Is that correct?
>
> If so, that sounds similar to
> https://blueprints.launchpad.net/neutron/+spec/provider-network-partial-specs,
> which is being implemented in the ML2 plugin for icehouse. I would not
> expect a similar feature to be implemented for the openvswitch
> monolithic plugin, since that is being deprecated.
>
>>
>> what's your opinion?
>
> If I understand it correctly, I agree this feature could be useful.
>
> -Bob
>
>>
>> Thanks!
>>
>> 2014-02-24 21:50 GMT+08:00 Robert Kukura <rkukura at redhat.com>:
>>> On 02/24/2014 07:09 AM, 黎林果 wrote:
>>>> Hi stackers,
>>>>
>>>>   When create a network, if we don't set provider:network_type,
>>>> provider:physical_network or provider:segmentation_id, the
>>>> network_type will be from cfg, but the other tow is from db's first
>>>> record. Code is
>>>>
>>>> (physical_network,
>>>>                      segmentation_id) = ovs_db_v2.reserve_vlan(session)
>>>>
>>>>
>>>>
>>>>   There has tow questions.
>>>>   1, network_vlan_ranges = physnet1:100:200
>>>>      Can we config much physical_networks by cfg?
>>>
>>> Hi Lee,
>>>
>>> You can configure multiple physical_networks. For example:
>>>
>>> network_vlan_ranges=physnet1:100:200,physnet1:1000:3000,physnet2:2000:4000,physnet3
>>>
>>> This makes ranges of VLAN tags on physnet1 and physnet2 available for
>>> allocation as tenant networks (assuming tenant_network_type = vlan).
>>>
>>> This also makes physnet1, physnet2, and physnet3 available for
>>> allocation of VLAN (and flat for OVS) provider networks (with admin
>>> privilege). Note that physnet3 is available for allocation of provider
>>> networks, but not for tenant networks because it does not have a range
>>> of VLANs specified.
>>>
>>>>
>>>>   2, If yes, the physical_network should be uncertainty. Dose this logical?
>>>
>>> Each physical_network is considered to be a separate VLAN trunk, so VLAN
>>> 2345 on physnet1 is a different isolated network than VLAN 2345 on
>>> physnet2. All the specified (physical_network,segmentation_id) tuples
>>> form a pool of available tenant networks. Normal tenants have no
>>> visibility of which physical_network trunk their networks get allocated on.
>>>
>>> -Bob
>>>
>>>>
>>>>
>>>> Regards!
>>>>
>>>> Lee Li
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list