Comment 18 for bug 1457900

Reviewed: https://review.openstack.org/186298
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=11e41664c2f13c2fb9dab9b42b79adac31e779a1
Submitter: Jenkins
Branch: stable/juno

commit 11e41664c2f13c2fb9dab9b42b79adac31e779a1
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 4aba83fd22c8880a2d24f27e43a32cc164abe3e0)