[Yahoo-eng-team] [Bug 1345947] Re: DHCPNAK after neutron-dhcp-agent restart
This grenade bug was last updated over 180 days ago, as grenade is a fast moving project and we'd like to get the tracker down to currently actionable bugs, this is getting marked as Invalid. If the issue still exists, please feel free to reopen it. ** Changed in: grenade Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1345947 Title: DHCPNAK after neutron-dhcp-agent restart Status in grenade: Invalid Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Released Bug description: After rolling out a configuration change, we restarted neutron-dhcp-agent service, and then dnsmasq logs start flooding: DHCPNAK ... lease not found. DHCPNAK is replied by dnsmasq for all DHCPREQUEST renews from all VMs. However the MAC and IP pairs exist in host files. The log flooding increases when more and more VMs start renewing and they keep retrying until IP expire and send DHCPDISCOVER and reinit the IP. The log flooding gradually disappears when the VMs IP expire and send DHCPDISCOVER, to which dnsmasq respond DHCPOFFER properly. Analysis: I noticed that option --leasefile-ro is used in dnsmasq command when started by neutron dhcp-agent. According to dnsmasq manual, this option should be used together with --dhcp-script to customize the lease database. However, the option --dhcp-script was removed when fixing bug 1202392. Because of this, dnsmasq will not save lease information in persistent storage, and when it is restarted, lease information is lost. Solution: Simply replace --leasefile-ro by --dhcp-leasefile=/lease would solve the problem. (patch attached) To manage notifications about this bug go to: https://bugs.launchpad.net/grenade/+bug/1345947/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1345947] Re: DHCPNAK after neutron-dhcp-agent restart
** Changed in: neutron/icehouse Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1345947 Title: DHCPNAK after neutron-dhcp-agent restart Status in Grenade - OpenStack upgrade testing: In Progress Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Bug description: After rolling out a configuration change, we restarted neutron-dhcp-agent service, and then dnsmasq logs start flooding: DHCPNAK ... lease not found. DHCPNAK is replied by dnsmasq for all DHCPREQUEST renews from all VMs. However the MAC and IP pairs exist in host files. The log flooding increases when more and more VMs start renewing and they keep retrying until IP expire and send DHCPDISCOVER and reinit the IP. The log flooding gradually disappears when the VMs IP expire and send DHCPDISCOVER, to which dnsmasq respond DHCPOFFER properly. Analysis: I noticed that option --leasefile-ro is used in dnsmasq command when started by neutron dhcp-agent. According to dnsmasq manual, this option should be used together with --dhcp-script to customize the lease database. However, the option --dhcp-script was removed when fixing bug 1202392. Because of this, dnsmasq will not save lease information in persistent storage, and when it is restarted, lease information is lost. Solution: Simply replace --leasefile-ro by --dhcp-leasefile=/lease would solve the problem. (patch attached) To manage notifications about this bug go to: https://bugs.launchpad.net/grenade/+bug/1345947/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1345947] Re: DHCPNAK after neutron-dhcp-agent restart
** Also affects: neutron/icehouse Importance: Undecided Status: New ** Changed in: neutron/icehouse Status: New => Fix Committed ** Changed in: neutron/icehouse Assignee: (unassigned) => Kevin Bringard (kbringard) ** Changed in: neutron/icehouse Importance: Undecided => High ** Changed in: neutron/icehouse Milestone: None => 2014.1.4 ** Tags removed: in-stable-icehouse in-stable-juno ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Importance: Undecided => High ** Changed in: neutron/juno Assignee: (unassigned) => Ihar Hrachyshka (ihar-hrachyshka) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1345947 Title: DHCPNAK after neutron-dhcp-agent restart Status in Grenade - OpenStack upgrade testing: In Progress Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in neutron juno series: Fix Committed Bug description: After rolling out a configuration change, we restarted neutron-dhcp-agent service, and then dnsmasq logs start flooding: DHCPNAK ... lease not found. DHCPNAK is replied by dnsmasq for all DHCPREQUEST renews from all VMs. However the MAC and IP pairs exist in host files. The log flooding increases when more and more VMs start renewing and they keep retrying until IP expire and send DHCPDISCOVER and reinit the IP. The log flooding gradually disappears when the VMs IP expire and send DHCPDISCOVER, to which dnsmasq respond DHCPOFFER properly. Analysis: I noticed that option --leasefile-ro is used in dnsmasq command when started by neutron dhcp-agent. According to dnsmasq manual, this option should be used together with --dhcp-script to customize the lease database. However, the option --dhcp-script was removed when fixing bug 1202392. Because of this, dnsmasq will not save lease information in persistent storage, and when it is restarted, lease information is lost. Solution: Simply replace --leasefile-ro by --dhcp-leasefile=/lease would solve the problem. (patch attached) To manage notifications about this bug go to: https://bugs.launchpad.net/grenade/+bug/1345947/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1345947] Re: DHCPNAK after neutron-dhcp-agent restart
** Changed in: neutron Status: Fix Committed => Fix Released ** Changed in: neutron Milestone: None => kilo-2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1345947 Title: DHCPNAK after neutron-dhcp-agent restart Status in Grenade - OpenStack upgrade testing: In Progress Status in OpenStack Neutron (virtual network service): Fix Released Bug description: After rolling out a configuration change, we restarted neutron-dhcp-agent service, and then dnsmasq logs start flooding: DHCPNAK ... lease not found. DHCPNAK is replied by dnsmasq for all DHCPREQUEST renews from all VMs. However the MAC and IP pairs exist in host files. The log flooding increases when more and more VMs start renewing and they keep retrying until IP expire and send DHCPDISCOVER and reinit the IP. The log flooding gradually disappears when the VMs IP expire and send DHCPDISCOVER, to which dnsmasq respond DHCPOFFER properly. Analysis: I noticed that option --leasefile-ro is used in dnsmasq command when started by neutron dhcp-agent. According to dnsmasq manual, this option should be used together with --dhcp-script to customize the lease database. However, the option --dhcp-script was removed when fixing bug 1202392. Because of this, dnsmasq will not save lease information in persistent storage, and when it is restarted, lease information is lost. Solution: Simply replace --leasefile-ro by --dhcp-leasefile=/lease would solve the problem. (patch attached) To manage notifications about this bug go to: https://bugs.launchpad.net/grenade/+bug/1345947/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1345947] Re: DHCPNAK after neutron-dhcp-agent restart
Grenade is affected because we need an upgrade patch to reflect the change in dhcp filters. ** Also affects: grenade Importance: Undecided Status: New ** Changed in: grenade Status: New => Confirmed ** Changed in: grenade Assignee: (unassigned) => Han Zhou (zhouhan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1345947 Title: DHCPNAK after neutron-dhcp-agent restart Status in Grenade - OpenStack upgrade testing: Confirmed Status in OpenStack Neutron (virtual network service): In Progress Bug description: After rolling out a configuration change, we restarted neutron-dhcp-agent service, and then dnsmasq logs start flooding: DHCPNAK ... lease not found. DHCPNAK is replied by dnsmasq for all DHCPREQUEST renews from all VMs. However the MAC and IP pairs exist in host files. The log flooding increases when more and more VMs start renewing and they keep retrying until IP expire and send DHCPDISCOVER and reinit the IP. The log flooding gradually disappears when the VMs IP expire and send DHCPDISCOVER, to which dnsmasq respond DHCPOFFER properly. Analysis: I noticed that option --leasefile-ro is used in dnsmasq command when started by neutron dhcp-agent. According to dnsmasq manual, this option should be used together with --dhcp-script to customize the lease database. However, the option --dhcp-script was removed when fixing bug 1202392. Because of this, dnsmasq will not save lease information in persistent storage, and when it is restarted, lease information is lost. Solution: Simply replace --leasefile-ro by --dhcp-leasefile=/lease would solve the problem. (patch attached) To manage notifications about this bug go to: https://bugs.launchpad.net/grenade/+bug/1345947/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
