Open Stack

Thanks! I'll reconsider about this.

2015-06-01 16:54 GMT+08:00 Kevin Benton <blak111 at 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.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
>
> __________________________________________________________________________
> 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/ed65b601/attachment.html>