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

2014-02-25 Thread 黎林果
 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 黎林果 lilinguo8...@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 rkuk...@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 rkuk...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-02-24 Thread 黎林果
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?

  2, If yes, the physical_network should be uncertainty. Dose this logical?


Regards!

Lee Li

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-02-24 Thread Robert Kukura
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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-02-24 Thread 黎林果
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 rkuk...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-02-24 Thread 黎林果
Yes. You are right.

The bp has implemented this function.

Thank you very much.

2014-02-25 11:01 GMT+08:00 Robert Kukura rkuk...@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 rkuk...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev