Open Stack

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 <rbryant at redhat.com>
To:     Hong Hui Xiao/China/IBM at IBMCN
Cc:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>, Carl Baldwin <carl at ecbaldwin.net>
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 <xiaohhui at cn.ibm.com> 
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