> 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 黎林果 <[email protected]>: > Yes. You are right. > > The bp has implemented this function. > > Thank you very much. > > 2014-02-25 11:01 GMT+08:00 Robert Kukura <[email protected]>: >> 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 <[email protected]>: >>>> 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 >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
