Comment 17 for bug 1457900

Reviewed: https://review.openstack.org/186300
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c07687c985703609ccc80f0151a2a40e2036a3f4
Submitter: Jenkins
Branch: stable/kilo

commit c07687c985703609ccc80f0151a2a40e2036a3f4
Author: Kevin Benton <email address hidden>
Date: Mon May 25 18:55:44 2015 -0700

    Persist DHCP leases to a local database

    Due to issues caused by dnsmasq restarts sending DHCPNAKs,
    change Ieff0236670c1403b5d79ad8e50d7574c1b694e34 passed the
    'dhcp-authoritative' option to dnsmasq. While this solved the
    restart issue, it broke the multi-DHCP server scenario because
    the dnsmasq instances will NAK requests to a server ID that
    isn't their own.

    Problem DHCP Request Lifecycle:

    Client: DHCPDISCOVER(broadcast)
    Server1: DHCPOFFER
    Server2: DHCPOFFER
    Client: DHCPREQUEST(broadcast with Server-ID=Server1)
    Server1: DHCPACK
    Server2: DHCPNAK(in response to observed DHCPREQUEST with other Server-ID)
              ^---Causes issues

    This change removes the authoritative option so NAKs are not
    send in response to DHCPREQUEST's to other servers. To handle
    the original issue that Ieff0236670c1403b5d79ad8e50d7574c1b694e34
    was inteded to address, this patch also allows changes to be persisted
    to a local lease file.

    In order to handle the issue where a DHCP server may be scheduled
    to another agent, a fake lease file is generated for dnsmasq to start
    with. The contents are populated based on all of the known ports for
    a network. This should prevent dnsmasq from NAKing clients renewing
    leases issued before it was restarted/rescheduled.

    Closes-Bug: #1457900
    Change-Id: Idc91602bf8c474467e596cbd5cbaa8898952c841
    (cherry picked from commit 98d8ad911d07a20af18edb0cac4bcf141a83d969)