<div dir="ltr"><span class=""></span><span class=""></span><div class="gmail_extra">Hi Carl,<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> A clear l3 agent manager interface with hookable methods would clearly simplify the understanding, the dev/support.<br>
</div><div class="gmail_extra"><br><br></div><div class="gmail_extra"></div><div class="gmail_extra">Difficulties:<br></div><div class="gmail_extra">1. (un)deployment method names are associated to the triggering event not to performed action: <br>
 - router deployment is done by _router_added</div><div class="gmail_extra"> - router gateway deployment/config is  done by  external_gateway_added<br></div><div class="gmail_extra"> - more generally (un)deployments are done by the associated *_added and *_removed methods <br>
</div><div class="gmail_extra">It implies to fully understand the behaviour of the L3 agent manager in order to check that (un)deployment actions are done and only done by the associated "triggering event" methods.<br>
</div><div class="gmail_extra">2. Because docstrings are missing, i needed to double check previous check.<br><br></div><div class="gmail_extra">3. Customization testing is not really easy, because inherited manager implementation could change. <br>
So i preferred to perform only black box tests to reduce coupling between implementation and tests.<br><br></div><div class="gmail_extra">4. Support: extending a class without a contract/interface implies to perform some adaptations/checks (not so much in practice) simplified by previous tests<br>
</div><div class="gmail_extra">But that's the topic !<br><br></div><div class="gmail_extra">5. It's not possible currently to change l3 agent manager through configuration<br> - so i must "develop" my own neutron-l3-agent binary implementation in order to allow providing a custom manager to main()<br>
</div><div class="gmail_extra"> - i must verify my binary was not erased during updates <br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra">Awkward:<br></div><div class="gmail_extra">6. (un)deployment methods get the router RouterInfo using different strategies:<br>
</div><div class="gmail_extra"> - _router_added builds it and stores it in self.router_info cache<br></div><div class="gmail_extra"> - _router_removed get it from self.router_info cache<br></div><div class="gmail_extra"> - external_gateway/internal_network_added/removed get it through arguments<br>
</div><div class="gmail_extra"><br>7._router_added and _process_routers have strange behaviours: <br></div><div class="gmail_extra"> - _process_routers calls _router_added will verifying to build router RouterInfo object<br>
</div><div class="gmail_extra"> - _router_added computes the router RouterInfo object and store it in self.router_info<br></div><div class="gmail_extra"> - _process_routers get it back from self.router_info<br></div><div class="gmail_extra">
IMHO, it seems more logical to let <br> - _process_routers builds and stores router RouterInfo object and <br> - _process_routers pass the object as an argument to _router_added<br></div><div class="gmail_extra">The same might apply to _router_removed and _process_routers ?<br>
<br><br></div><div class="gmail_extra"></div><div class="gmail_extra">I must share with pcm about "L3 Vendor plugins" BPs to verify my understanding and possible synergies.<br></div><div class="gmail_extra">But a priori [1] BP seems to be the only "synergy candidate".<br>
<br><br></div><div class="gmail_extra">Cedric<br><br><br>[1] <a href="https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation">https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation</a><br>
</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 6:18 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Cedric,<br>
<br>
I'm just getting back from a short vacation.  Please excuse the delayed reply.<br>
<br>
I have a feeling that this subject may have been discussed in the past<br>
before I was very active in Neutron.  So, others may chime in if I'm<br>
missing something.<br>
<br>
For the customizations that you're making, it sounds like some sort of<br>
hook system would work best.  You are currently using inheritance to<br>
achieve it but I worry that the L3 agent class has not been designed<br>
for this inheritance and may not be entirely suitable for your needs.<br>
What has been your experience?  Have you found it easy to maintain<br>
your subclass as the L3 agent evolves?  If not, what problems have you<br>
seen?  Are there parts of the agent design that made it difficult or<br>
awkward?<br>
<br>
I suspect that a well-designed and stable hook system will better suit<br>
your needs in the long run.  However, nothing like that exists in the<br>
agent now.<br>
<br>
Is there some synergy here with the "L3 Vendor plugins" summit topic<br>
proposal [1].  Could you look through that proposal and the linked<br>
blueprints with that in mind?<br>
<br>
Carl<br>
<br>
[1] <a href="http://summit.openstack.org/cfp/details/81" target="_blank">http://summit.openstack.org/cfp/details/81</a><br>
<div><div class="h5"><br>
On Fri, Apr 18, 2014 at 9:11 AM, zz elle <<a href="mailto:zzelle@gmail.com">zzelle@gmail.com</a>> wrote:<br>
> Hi everyone,<br>
><br>
><br>
> I would like to propose a change to simplify/allow l3 agent manager<br>
> customization and i would like the community feedback.<br>
><br>
><br>
> Just to precise my context, I deploy OpenStack for small specific business<br>
> use cases and i often customize it because of specific use case needs.<br>
> In particular must of the time i must customize L3 agent behavior in order<br>
> to:<br>
> - add custom iptables rules in the router (on router/port post-deployment),<br>
> - remove custom iptables rules in the router (on port pre-undeployment),<br>
> - update router config through sysctl (on router post-deployment),<br>
> - start an application in the router (on router/port post-deployment),<br>
> - stop an application in the router (on router/port pre-undeployment),<br>
> - etc ...<br>
> Currently (Havana,Icehouse), i create my own L3 agent manager which extends<br>
> neutron one.<br>
> And I replace neutron-l3-agent binary, indeed it's not possible to<br>
> change/hook l3 agent manager implementation by configuration.<br>
><br>
><br>
> What would be the correct way to allow l3 agent manager customization ?<br>
>  - Allow to specify l3 agent manager implementation through configuration<br>
>   ==> like the option router_scheduler_driver which allows to change router<br>
> scheduler implementation<br>
>  - Allow to hook l3 agent manager implementation<br>
>   ==> like the generic hook system in nova (nova.hooks used in<br>
> nova.compute.api)<br>
>   ==> or like the neutron ML2 mechanism hook system<br>
> (neutron.plugins.ml2.driver_api:MechanismDriver)<br>
>  - Other idea ?<br>
><br>
><br>
> It seems the same question could be asked for the dhcp agent ?<br>
><br>
><br>
> Thanks,<br>
><br>
> Cedric (zzelle@irc)<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div>