[ovs-dev] [PATCH RFC v3] ovn-northd: add default_dhcpvx_options for Logical_Switch

[Zong Kai Li]

On Thu, Sep 15, 2016 at 7:48 AM, Ben Pfaff <blp at ovn.org> wrote:
> On Thu, Sep 01, 2016 at 09:56:30AM +0000, Zongkai LI wrote:
>> This patch adds default_dhcpv4_options and default_dhcpv6_options columns for
>> Logical_Switch, which should help CMS not to calculate and set dhcpv4_options
>> and dhcpv6_options columns for lswitch ports on lswitchs one by one, when
>> most of lswitch ports on the same lswitch are using the DHCPv4_Options and
>> DHCPv6_Options. Default DHCP(v4 and v6) Options should benefit in case
>> scalling up and DB synchronization between CMS and OVN NB.
>>
>> v1 -> v2
>> add ACL lflows support for lswitch ports using default_dhcpvx_options from
>> lswitch.
>>
>> v2 -> v3
>> update ovn dhcpv4 and dhcpv6 tests for lswitch ports using specific dhcp
>> options than defualt ones in lswitch.
>
> The CMS can point the multiple dhcpvx_options column in as many rows as
> it likes to the same row in the DHCP_Options table, so I don't know why
> this offers an advantage.

Sorry for my poor english, I couldn't get your points well.
"The CMS can point the multiple dhcpvx_options column in as many rows
as it likes to the same row in the DHCP_Options table", do you mean
the CMS can point multiple options in a DHCP_Options row option column
? This patch won't help CMS on that.

The deep reason I submitted this patch is, we locate a DHCP_Options
row for Logical_Switch_Port.dhcpvx_options to refer by scanning
DHCP_Options table to find a row matching some rules we defined. Like
"subnet_id" and "port_id" defined in external_ids column, the
OpenStack integrator, networking-ovn uses them to locate a certain
DHCP_Options row for a port to set its dhcpvx_options.

It works, but not necessary for case [1] most ports from the same
logical-switch using the same dhcpvx_options, since we will locate the
same uuid duplicately.
It's possible for CMS to use some cache to store mappings between
networks/subnets and  DHCP_Options rows uuids, but I don't think this
is a CMS-friendly approach.

By adding default dhcpvx options in Logical_Switch, CMS will skip the
scanning step for ports using the default dhcp options cases, such as
creating a new port, logical switch port lost with/without dhcp
options lost(or become stale) when DB sync, and logical switch port
exist but dhcp options lost when DB sync.

This is a option way let CMS to handle dhcp options, it won't change
current approach how DHCP_Options and
Logical_Switch_Port.dhcpvx_options works. It won't benefit too much
scenarios, but at least for case [1] it would.

Thanks,
Zongkai, LI