<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Zzelle, Carl and others,</div>
<div><br>
</div>
<div>We’ve been doing work on a more modular agent whose responsibilities are basically to:</div>
<div>1: apply configurations in devices when Neutron service resources (like Neutron Routers) are created or updated.</div>
<div>2: monitor the health of devices hosting such service resources</div>
<div><br>
</div>
<div>Our starting point was the l3 agent which we’ve then evolved to become a configuration agent. </div>
<div>It can perform configurations in remote devices so it does not have to run locally on the device it configures </div>
<div>(this helps to reduce agent reporting traffic and thus the load on the Neutron service)</div>
<div>It makes use of device drivers that knows how to instantiate/manipulate service resources in devices of the type that the driver handles.</div>
<div>It also introduces what we call service helpers. Such a helper (a python class) essentially describes the workflow that should be used to create/update Neutron resources of a certain type.</div>
<div>At the moment we have a single service helper for Neutron routing service but our thinking is to take this one step further and allow for different service helpers for each service.</div>
<div>That would allow for pretty much completely different workflows to be used if a Neutron router is implemented in say a device of type A, vs if it is implemented in device of type B.</div>
<div><br>
</div>
<div>Perhaps something like the config agent could help handling some of the complexities you bring up. In case your interested you can have a look at the BP for the config agent. The link for blueprint spec is:</div>
<div>
<div><a rel="nofollow" href="https://review.openstack.org/#/c/90729/" style="color: purple;">https:/<wbr>/review.<wbr>openstack.<wbr>org/#/c/<wbr>90729/</a></div>
</div>
<div><br>
</div>
<div>We hope to at least briefly be able to bring up the configuration agent in the design summit session on the service vm framework (on Friday, shared session with Isaku Yamahata) as that is the context in which we started this work.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Bob</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>ZZelle <<a href="mailto:zzelle@gmail.com">zzelle@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>torsdag 24 april 2014 00:34<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron][L3] Agent manager customization<br>
</div>
<div><br>
</div>
<div>
<div>
<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>
</div>
</div>
</span>
</body>
</html>