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

黎林果 lilinguo8212 at gmail.com
Wed Feb 26 06:33:38 UTC 2014


> I would not expect a similar feature to be implemented for the openvswitch monolithic plugin, since that is being deprecated.

What's the relation of ML2 and other plugins?

I found the create_subnet only implemented in ML2 bug not in openvswith.


2014-02-25 11:54 GMT+08:00 黎林果 <lilinguo8212 at gmail.com>:
> 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