dhcp_release6 can be called when it is not present

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

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.

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

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

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.

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?

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.

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

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.

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

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

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

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

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.

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

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

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