dhcp_release6 can be called when it is not present

[Brian Haley]

If someone enables dhcpv6-stateful addressing on a subnet, but they are running an old version of dnsmasq (<2.76), then the dhcp agent could try and run dhcp_release6 even though it isn't present. An example:

http://logs.openstack.org/53/365653/5/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial/813d16d/logs/screen-q-dhcp.txt.gz#_2016-09-06_11_40_02_272

Checking it's present first would fix this problem.

Since the change to call dhcp_release6 was just added in https://review.openstack.org/#/c/301747/ we should fix this before Newton ships and people complain.

There is also an effort to get Cirros to support DHCPv6 so that we can test this in the gate,
https://bugs.launchpad.net/cirros/+bug/1487041 - hopefully that gets done so we can add a functional test.

[Armando Migliaccio (armando-migliaccio)]

If a deployment requires IPv6, the right dependencies should be installed. I wonder if this demands for a revert in Newton.

[Brian Haley (brian-haley)]

We do have code in the sanity check scripts to detect the new version of dnsmasq, so someone deploying it should see the error if they run it.

I would rather not revert just because the failure of running dhcp_release6 is caught, so doesn't cause any collateral damage. Previously we would call dhcp_release with an IPv6 address and fail just as miserably.

[Ihar Hrachyshka (ihar-hrachyshka)]

I added Ubuntu dnsmasq package to affected projects to raise visibility around missing dependency for OpenStack Neutron in Xenial dnsmasq package.

[Ihar Hrachyshka (ihar-hrachyshka)]

Fix: https://review.openstack.org/#/c/366291/

[Brian Haley (brian-haley)]

The NoFilterMatched is actually because the grenade job doesn't automatically update dhcp.filters, I have a fix proposed there that I'll update with this bug info, https://review.openstack.org/#/c/371015/

There is still a fix required for neutron to catch when we don't have dhcp_release6, I'll update the existing patch based on multiple comments from Ihar and others.

[Carl Baldwin (carl-baldwin)]

I don't want to revert the original fix because I don't think that gets us to a better place. With that fix in place, at least deployers have a chance of seeing from the sanity check that they need to update dnsmasq to a higher minimum version in order to use stateful IPv6. If they see it and update dnsmasq, then stateful IPv6 has a chance of working. If we revert then we have no chance of it working.

Ideally, from a end user's point of view, we'd generate an API error if the agents aren't going to be able to handle a stateful IPv6 subnet. So, I think we should work toward that. But, to accomplish that, we'll end up with a fix that cannot be backported to Newton, right?

[Ihar Hrachyshka (ihar-hrachyshka)]

I suggest we don't modify API behaviour based on broken agent setup. It would require a lot of coordination... for what? Setups are not supposed to be broken, we should rely on runtime deps being installed.

[Ihar Hrachyshka (ihar-hrachyshka)]

btw this bug suggests that we don't have a tempest scenario that would mess with ipv6 leases for stateful subnets.

[Ihar Hrachyshka (ihar-hrachyshka)]

Actually, the impact here is actually making allocation reloading completely broken for dhcpv6-stateful networks, something that was not completely clear to me until I read the code.

I actually now prefer we get it in rc2.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/375645

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/366291
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d4f92ede9ed52cd0b9059d993e3cf1f42d5ff57e
Submitter: Jenkins
Branch: master

commit d4f92ede9ed52cd0b9059d993e3cf1f42d5ff57e
Author: Brian Haley <email address hidden>
Date: Tue Sep 6 14:44:41 2016 -0400

    Fix dhcp_release6 error when not supported

    If the system does not have a version of dnsmasq that supports
    dhcp_release6, warn about but otherwise handle it gracefully, and also
    don't even try to execute it the next time.

    Closes-Bug: #1622002
    Related-Bug: #1624079
    Change-Id: I6bb9547f9d9a9fcfb2357521f3f5bd1dc1dd5136

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/375645
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f74a6c047f02e077e4fd943e2eb256df82e05509
Submitter: Jenkins
Branch: stable/newton

commit f74a6c047f02e077e4fd943e2eb256df82e05509
Author: Brian Haley <email address hidden>
Date: Tue Sep 6 14:44:41 2016 -0400

    Fix dhcp_release6 error when not supported

    If the system does not have a version of dnsmasq that supports
    dhcp_release6, warn about but otherwise handle it gracefully, and also
    don't even try to execute it the next time.

    Closes-Bug: #1622002
    Related-Bug: #1624079

    (cherry picked from commit d4f92ede9ed52cd0b9059d993e3cf1f42d5ff57e)
    Change-Id: I6bb9547f9d9a9fcfb2357521f3f5bd1dc1dd5136

[Christian Ehrhardt  (paelzer)]

Hi,
since this is now fix released, can we drop the dnsmasq task which seemed to be added only for visibility?

[Brian Haley (brian-haley)]

Christian - I believe we added dnsmasq in order to see about getting v2.76 into LTS (xenial) since having a better dhcpv6 stateful offering would be a good thing. It's currently only in Y.

[Ihar Hrachyshka (ihar-hrachyshka)]

Right, we need the dhcp_release6 tool in xenial dnsmasq package.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 9.0.0.0rc2 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 10.0.0.0b1 development milestone.