>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