<div dir="ltr"><div>Hi everyone,<br><br><br></div>Draft neutron spec has been defined to cover such case: <a href="https://review.openstack.org/99356">https://review.openstack.org/99356</a><br><br><pre>Thanks for your feedbacks,

Cedric (<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">zzelle at irc</a>)</pre><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 7:27 PM, ZZelle <span dir="ltr"><<a href="mailto:zzelle@gmail.com" target="_blank">zzelle@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><pre>Hi everyone,

<br>I would like to propose a change to allow/simplify dhcp agent manager
customization (like the l3-agent-consolidation spec) and i would like the community feedback.


Just to precise my context, I deploy OpenStack for small specific business
use cases and i often customize it because of specific use case needs.
In particular sometimes i must customize dhcp agent behavior in order
to:
- add custom iptables rules in the dhcp namespace (on dhcp post-deployment),
- remove custom iptables rules in the dhcp namespace (on dhcp pre-undeployment),
- start an application like the metadata-proxy in the dhcp namespace for isolated networks (on dhcp post-deployment/update),
- stop an application in the dhcp namespace for isolated networks (on dhcp pre-undeployment/update),
- etc ...
Currently (Havana,Icehouse), i create my own DHCP agent manager which extends
neutron one and allows to define pre/post dhcp (un)deployment
And I replace neutron-dhcp-agent binary, indeed it's not possible to
change/hook dhcp agent manager implementation by configuration.<br><br><br></pre><pre>What would be the correct way to allow dhcp agent manager customization ?<br></pre><pre>For my need, allowing to:<br> - specify dhcp agent manager implementation through configuration and 
 - add 4 methods (pre/post dhcp (un)deployment)in dhcp manager workflow with empty implementation that can replaced using subclass <br></pre><pre>would be enough.<br><br></pre><pre>Based on other needs, a mechanism principle could be better or a monkey_patch approach (as in nova) could be more generic.<br>


</pre><pre><br><br>I have the feeling that the correct way mustly depends on how such feature could interest the community.<br><br><br>
Thanks for your feedbacks,

Cedric (<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">zzelle at irc</a>)</pre></div></div>
</blockquote></div><br></div>