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 <[email protected]> To: Hong Hui Xiao/China/IBM@IBMCN Cc: "OpenStack Development Mailing List (not for usage questions)" <[email protected]>, Carl Baldwin <[email protected]> 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 <[email protected]> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
