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. what's your opinion? 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
