[RFE] Add a driver for isc-dhcpd

I like it.
but seems we need to refactor it by https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#rfe-submission-guidelines

Thanks gongysh! I will refactor it according to the guidelines.

This makes some sense, marking confirmed.

Ideally, this needs to happen once we split out the reference implementation, and this new driver could live in that tree with the existing DHCP agent. There is also the process of ensuring the existing driver can support this type of pluggability.

Related fix proposed to branch: master
Review: https://review.openstack.org/212836

Honestly, I always thought that the answer would be to handle dhcp traffic right on the vswitch. That said, the code to handle the dhcp process is so convoluted at times that I am not sure switching/enabling something else is worth the pain.

To discuss at the drivers meeting.

 it would be great if the bug description explains the merit(s) of adopting isc-dhcp more clearly.
If you have some result of isc-dhcp performance on updating dhcp entries, it would be nice.
If isc-dhcp can support the current neutron model well, it sounds good to me for better management performance and stability(?).

I think having another dhcp back-end is a good start to improve dhcp driver interface.

Another question is whether we maintain another dhcp driver or not.
how to cover multiple drivers in our gate is a big question.

The dhcp driver interface is already pluggable, and adding support for isc-dhcpd might lead to some refinements. Hopefully it's not too much work, but I am personally not convinced that yet another driver is really the answer to the limitations hinted here.

I'd rather look at the extent of the code involved before judging whether a sub-project makes sense or not. So if you want to start coding, feel free to do so and we'll evaluate the impact on the existing code base.

@Armando,

Does this mean the spec https://review.openstack.org/#/c/212836/ needs to be merged in Mitaka-1? A bit confused.

@Shraddha,

See http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements

Somewhere in there it says:

"As for setting the milestone (both for RFE bugs or blueprints), the current milestone is always chosen, assuming that work will start as soon as the feature is approved. Work that fails to complete by the defined milestone will roll over automatically until it gets completed or abandoned."

Change abandoned by Doug Wiegley (<email address hidden>) on branch: master
Review: https://review.openstack.org/212836
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Expired for neutron because there has been no activity for 60 days.]