Open Stack

>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.devops at 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 <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
>>
>>
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150601/418cedeb/attachment.html>