On Fri, Jun 24, 2016 at 8:21 AM, Numan Siddique <nusid...@redhat.com> wrote:
> > > On Fri, Jun 24, 2016 at 4:13 AM, Ben Pfaff <b...@ovn.org> wrote: > >> On Wed, Jun 15, 2016 at 02:48:27PM +0530, Numan Siddique wrote: >> > OVN implements a native DHCP support which caters to the common >> > use case of providing an IP address to a booting instance by >> > providing stateless replies to DHCP requests based on statically >> > configured address mappings. To do this it allows a short list of >> > DHCP options to be configured and applied at each compute host >> > running ovn-controller. >> > >> > A new table 'Subnet' is added in OVN NB DB to store the DHCP options. >> > >> > For each logical port following flows are added if the CMS has defined >> > DHCP options in the 'Subnet' column >> > >> > - A logical flow which copies the DHCP options to the DHCP >> > request packets using the 'put_dhcp_opts' action and advances the >> > packet to the next stage. >> > >> > - A logical flow which implements the DHCP reponder by sending >> > the DHCP reply back to the inport once the 'put_dhcp_opts' action >> > is applied. >> > >> > Signed-off-by: Numan Siddique <nusid...@redhat.com> >> > Co-authored-by: Ben Pfaff <b...@ovn.org> >> > Signed-off-by: Ben Pfaff <b...@ovn.org> >> >> I would have expected that whether to enable DHCP and what DHCP options >> to use would be primarily a property of a logical switch port. Thus, I >> would have expected to add DHCP option information to >> Logical_Switch_Port or (since it turns out there's quite a lot of it and >> it's likely to be mostly the same from one port to another) a reference >> from Logical_Switch_Port to a row in some new DHCP_Options table. >> >> I don't know whether I actually object to your design though, because I >> haven't spent much time studying it yet, so I'd like to hear your (and >> others') opinion on the pluses and minuses of each possibility. Can you >> say a little about it? >> >> > > Thanks Ben for the review and your comments. > > I thought of having a Subnet table and storing DHCP options because > - most of the DHCP options are common to all the logical ports with the > same subnet cidr. > - Open > S > tack neutron has a subnet table and it spawns the "dnsmasq" process to > handle the DHCP requests when the subnet is created. So > thought of following the similar approach. > - and I never thought of the approach you mentioned. > > The biggest minus i see with my approach is > - In cases where a logical port wants to override or add new DHCP > options, it has to define it in > the Logical_Switch_Port.options column with the prefix "dhcp_opt_". > Also if the admin wants to disable DHCP on a particular logical port > > she has to define "dhcp_disabled" in the options column. This doesn't look > very clean when > > compared to the approach you mentioned. > > I think the approach you mentioned is more cleaner. All the logical ports > can refer to the same row of > > the new DHCP options table. In cases where logical port wants to override, > the logical port can refer to a new row. > > With your approach, the CMS has to do a bit more work compared to the > first approach, but I think that > ' > s fine. > > Ben, I think creating a new table DHCP_Options and Logical ports referencing this table seems better and cleaner to me. I have submitted the patch here - [1] based on this. [1] - https://patchwork.ozlabs.org/patch/640977/ Thanks Numan > > >> Thanks, >> >> Ben. >> > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
