Thanks! I'll reconsider about this. 2015-06-01 16:54 GMT+08:00 Kevin Benton <blak...@gmail.com>:
> >But I don't know that does NAK matters? > > Yes, some clients will honor it and re-request, so they end up in a loop. > I believe the dhcp client in the Cirros image does this. > > >"dhcp-authoritative" is really a simple way to solve the problem of that > dnsmasq will lose lease if restarted > > Yes, unfortunately it made dnsmasq behave authoritatively though. :-) The > patch that merged should fix the NAK issue and the lease lost on restart > issue. > > On Mon, Jun 1, 2015 at 1:47 AM, Damon Wang <damon.dev...@gmail.com> wrote: > >> Hi Benton, >> >> I'm sorry that seems I missed your discuss. I just seen your patch's >> merge yesterday. >> >> But I don't know that does NAK matters? A client will get a ACK and a NAK >> if there are two agents, it's ok because client will assign IP address >> successfully according to the ACK. >> >> "dhcp-authoritative" is really a simple way to solve the problem of that >> dnsmasq will lose lease if restarted, and we have put this patch to our >> production (public cloud), it works well. >> >> Thanks! >> Wei >> >> 2015-05-28 6:39 GMT+08:00 Kevin Benton <blak...@gmail.com>: >> >>> >Looking at [1], I don't see that it generates a script at all. What it does >>> is it prepopulates a lease file for dnsmasq consumption (so there is no >>> external shell involved). Do we talk about the same patch? >>> >>> Not that patch. In the first email, I mentioned 3 approaches: iptables, >>> lease db generation, and script generation. I didn't put something up for >>> script generation because it was basically the same thing is the lease db >>> generation with an echo statement at the top. >>> >>> I was just pointing out that the script approach I was using was >>> suggesting was quite different from the other one up for review. But it >>> doesn't really matter because the lease DB is the easy way to go. >>> >>> >>> On Wed, May 27, 2015 at 4:57 AM, Ihar Hrachyshka <ihrac...@redhat.com> >>> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> On 05/26/2015 11:53 PM, Kevin Benton wrote: >>>> >> Actually, that approach was initially taken for bug 1345947, but >>>> > then the patch was abandoned to be replaced with a simpler - >>>> > --dhcp-authoritative approach that ended up with unexpected NAKs >>>> > for multi agent setup. >>>> > >>>> >> See: https://review.openstack.org/#/c/108272/12 >>>> > >>>> > So I had seen that patch but it's quite different from the approach >>>> > I was taking. That one requires a new script in the 'bin' >>>> > directory, a new entry in setup.cfg, an a new dhcp filter entry for >>>> > rootwrap. Is that something you would be comfortable back-porting >>>> > all of the way back to Icehouse? >>>> >>>> I agree that a patch without a new script and, more importantly, >>>> without a rootwrap filter modification, is a lot better than the one I >>>> cited above. >>>> >>>> > >>>> > The approach I was using was to generate the script at runtime in >>>> > the data directory for each instance to just return the addresses >>>> > directly. That way there are no setup changes or new entries in >>>> > bin. Personally, I felt it was easier to understand since it simply >>>> > generated a big echo statement, but I might be biased because I >>>> > wrote it. :) >>>> > >>>> >>>> Looking at [1], I don't see that it generates a script at all. What it >>>> does is it prepopulates a lease file for dnsmasq consumption (so there >>>> is no external shell involved). Do we talk about the same patch? >>>> >>>> I've checked [1], and it seems like the best approach, both from code >>>> complexity and "backportability" perspective. I've left some comments >>>> there. >>>> >>>> [1]: https://review.openstack.org/#/c/185486/ >>>> >>>> Ihar >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2 >>>> >>>> iQEcBAEBCAAGBQJVZbE8AAoJEC5aWaUY1u57ufkH/RfsQJy+Ddz3f+L37mNY28uj >>>> h+gLaiJIcZ1iMKKMo1tpg881u/aKpy3LlScoKHLnwWXub/IPxrxN2+/IMfCoF9iV >>>> ZbgtmggVRh/TjHOMbMpQVqJ+J8qe4TN29kW5x1RcUEecYy/hbyyKeBYoLlEXoZhn >>>> GzWcWyx9yp2qSOqe9010K+nmXdAzD+jg8/YJlBtP/ggO0qoWB7Is/D2bHkoeCPsd >>>> uqJzhAAZg4w2hhPgKpb1aUhyQU9uE5gzj5Yh5PE+kvINDRwLTLoqWQ7sxpR1hiqH >>>> rZ8t8FE1wmdQKEWrsRVy6/2pLOziKVNGPinBLYwwBUGY+S7kb2Jc6AgAHrAx/iY= >>>> =Wnx+ >>>> -----END PGP SIGNATURE----- >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Kevin Benton >>> >>> >>> __________________________________________________________________________ >>> 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 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 >> >> > > > -- > Kevin Benton > > __________________________________________________________________________ > 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 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