Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
On Mon, Mar 21, 2016 at 12:26 PM, Russell Bryant wrote: > On Thu, Mar 17, 2016 at 1:45 AM, Hong Hui Xiao > wrote: > >> Hi Russell. >> >> Since the "ovn-bridge-mapping" will become accessible in OVN Southbound >> DB, do you meant that neutron plugin can read those bridge mappings from >> the OVN Southbound DB? I didn't think in that way because I thought >> networking-ovn will only transact data with OVN Northbound DB. >> > > You're right that networking-ovn currently only uses the OVN northbound > DB. This requirement crosses the line into physical space and needing to > know about some physical environment details, so reading from the > southbound DB for this info is acceptable. > > >> Also, do you have any link to describe the ongoing work in OVN to sync the >> "ovn-bridge-mapping" from hypervisor? > > > This patch introduces some new tables to the southbound DB: > > http://openvswitch.org/pipermail/dev/2016-March/068112.html > > I was thinking that we would be able to read the physical endpoints table > to get what we need, but now I'm thinking it may not fit our use case. > > The alternative would be to just store the bridge mappings as an > external_id on the Chassis record in the southbound database. How quickly > is this needed? > This is now ready. The Chassis table in OVN_Southbound now has 1) a hostname column 2) an external_ids column, including an ovn-bridge-mappings key. Between those two, I think the Neutron plugin has all of the info it needs. Let me know if you think of anything else that is missing. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
On Thu, Mar 17, 2016 at 1:45 AM, Hong Hui Xiao wrote: > Hi Russell. > > Since the "ovn-bridge-mapping" will become accessible in OVN Southbound > DB, do you meant that neutron plugin can read those bridge mappings from > the OVN Southbound DB? I didn't think in that way because I thought > networking-ovn will only transact data with OVN Northbound DB. > You're right that networking-ovn currently only uses the OVN northbound DB. This requirement crosses the line into physical space and needing to know about some physical environment details, so reading from the southbound DB for this info is acceptable. > Also, do you have any link to describe the ongoing work in OVN to sync the > "ovn-bridge-mapping" from hypervisor? This patch introduces some new tables to the southbound DB: http://openvswitch.org/pipermail/dev/2016-March/068112.html I was thinking that we would be able to read the physical endpoints table to get what we need, but now I'm thinking it may not fit our use case. The alternative would be to just store the bridge mappings as an external_id on the Chassis record in the southbound database. How quickly is this needed? -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
On Tue, Mar 15, 2016 at 7:02 PM, Hong Hui Xiao wrote: > Hi all. > > I did some investigation recently. And I think we can start some > discussion now. > > All below thinking is based on the current implementation of neutron. With > routed network, a subnet will be considered as a L2 domain. Things might > change. > > I think routed network in OVN can implement in this way: > User creates provider network. For example: > neutron net-create provider-101 --shared \ > --provider:physical_network providernet \ > --provider:network_type vlan \ > --provider:segmentation_id 101 > > These attributes "--provider:physical_network" will be recorded in the > external_ids of Logical_Switch in OVN_Northbound. > > > > To Russell: > I will expect OVN to do the following things. > 1) The OVN_Southbound will have the latest information of > "ovn-bridge-mappings" of each Chassis. > 2) After creating a new network with "provider:physical_network" set, the > OVN will update Logical_Switch in OVN_Northbound. > The Logical_Switch will have new key:value pair in external_ids. > neutron:available_hosts="compute-host1,compute-host2" > 3) When a compute host join/leave the OpenStack topology, or a compute > host just updates its ovn-bridge-mappings, OVN should updated > Logical_Switch with related physical_network. This is a bottom-up change, > which is similar to the port status change. > 4) networking-ovn should be able to catch the update of Logical_Switch in > 2) & 3) and update the SegmentHostMapping, which will be introduced in > [2]. > > I think 1) 2) & 3) need additional work in OVN code. And 4) need code > change in networking-ovn. > There's some work happening in OVN where the information currently in ovn-bridge-mappings on each hypervisor will become accessible in the OVN Southbound database. As a nice side effect, the Neutron plugin should be able to read those bridge mappings from the OVN database and have all of the information it needs. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
Hi Russell. Since the "ovn-bridge-mapping" will become accessible in OVN Southbound DB, do you meant that neutron plugin can read those bridge mappings from the OVN Southbound DB? I didn't think in that way because I thought networking-ovn will only transact data with OVN Northbound DB. Also, do you have any link to describe the ongoing work in OVN to sync the "ovn-bridge-mapping" from hypervisor? Thanks Hong Hui Xiao From: Russell Bryant To: Hong Hui Xiao/China/IBM@IBMCN Cc: "OpenStack Development Mailing List (not for usage questions)" , Carl Baldwin Date: 03/17/2016 10:36 Subject: Re: [openstack-dev][networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping) On Tue, Mar 15, 2016 at 7:02 PM, Hong Hui Xiao wrote: Hi all. I did some investigation recently. And I think we can start some discussion now. All below thinking is based on the current implementation of neutron. With routed network, a subnet will be considered as a L2 domain. Things might change. I think routed network in OVN can implement in this way: User creates provider network. For example: neutron net-create provider-101 --shared \ --provider:physical_network providernet \ --provider:network_type vlan \ --provider:segmentation_id 101 These attributes "--provider:physical_network" will be recorded in the external_ids of Logical_Switch in OVN_Northbound. To Russell: I will expect OVN to do the following things. 1) The OVN_Southbound will have the latest information of "ovn-bridge-mappings" of each Chassis. 2) After creating a new network with "provider:physical_network" set, the OVN will update Logical_Switch in OVN_Northbound. The Logical_Switch will have new key:value pair in external_ids. neutron:available_hosts="compute-host1,compute-host2" 3) When a compute host join/leave the OpenStack topology, or a compute host just updates its ovn-bridge-mappings, OVN should updated Logical_Switch with related physical_network. This is a bottom-up change, which is similar to the port status change. 4) networking-ovn should be able to catch the update of Logical_Switch in 2) & 3) and update the SegmentHostMapping, which will be introduced in [2]. I think 1) 2) & 3) need additional work in OVN code. And 4) need code change in networking-ovn. There's some work happening in OVN where the information currently in ovn-bridge-mappings on each hypervisor will become accessible in the OVN Southbound database. As a nice side effect, the Neutron plugin should be able to read those bridge mappings from the OVN database and have all of the information it needs. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
Hi all. I did some investigation recently. And I think we can start some discussion now. All below thinking is based on the current implementation of neutron. With routed network, a subnet will be considered as a L2 domain. Things might change. I think routed network in OVN can implement in this way: User creates provider network. For example: neutron net-create provider-101 --shared \ --provider:physical_network providernet \ --provider:network_type vlan \ --provider:segmentation_id 101 These attributes "--provider:physical_network" will be recorded in the external_ids of Logical_Switch in OVN_Northbound. To Russell: I will expect OVN to do the following things. 1) The OVN_Southbound will have the latest information of "ovn-bridge-mappings" of each Chassis. 2) After creating a new network with "provider:physical_network" set, the OVN will update Logical_Switch in OVN_Northbound. The Logical_Switch will have new key:value pair in external_ids. neutron:available_hosts="compute-host1,compute-host2" 3) When a compute host join/leave the OpenStack topology, or a compute host just updates its ovn-bridge-mappings, OVN should updated Logical_Switch with related physical_network. This is a bottom-up change, which is similar to the port status change. 4) networking-ovn should be able to catch the update of Logical_Switch in 2) & 3) and update the SegmentHostMapping, which will be introduced in [2]. I think 1) 2) & 3) need additional work in OVN code. And 4) need code change in networking-ovn. To Carl: At the same time, the plugin(ml2 or networking-ovn) will provide a "new" interface. The "new" interface might be the same with [1]. Neutron will use this interface select routed hosts for a network. Any thoughts? [1] neutron.plugins.ml2.plugin.Ml2Plugin.filter_hosts_with_network_access @ https://review.openstack.org/#/c/205631/33 [2] https://review.openstack.org/#/c/285548/1 Thanks HongHui Xiao(肖宏辉) PMP® OpenStack Network development, Beijing, China Email: xiaoh...@cn.ibm.com Tel: 86-10-82453130 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
