[openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
Damon Wang
damon.devops at gmail.com
Mon Jun 1 08:47:50 UTC 2015
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 <blak111 at 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 <ihrachys at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150601/a672f2df/attachment.html>
More information about the OpenStack-dev
mailing list