Hi Zzelle, Carl and others, We’ve been doing work on a more modular agent whose responsibilities are basically to: 1: apply configurations in devices when Neutron service resources (like Neutron Routers) are created or updated. 2: monitor the health of devices hosting such service resources
Our starting point was the l3 agent which we’ve then evolved to become a configuration agent. It can perform configurations in remote devices so it does not have to run locally on the device it configures (this helps to reduce agent reporting traffic and thus the load on the Neutron service) It makes use of device drivers that knows how to instantiate/manipulate service resources in devices of the type that the driver handles. 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. 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. 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. 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: https://review.openstack.org/#/c/90729/ 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. Thanks, Bob From: ZZelle <[email protected]<mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Date: torsdag 24 april 2014 00:34 To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [Neutron][L3] Agent manager customization Hi Carl, A clear l3 agent manager interface with hookable methods would clearly simplify the understanding, the dev/support. Difficulties: 1. (un)deployment method names are associated to the triggering event not to performed action: - router deployment is done by _router_added - router gateway deployment/config is done by external_gateway_added - more generally (un)deployments are done by the associated *_added and *_removed methods 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. 2. Because docstrings are missing, i needed to double check previous check. 3. Customization testing is not really easy, because inherited manager implementation could change. So i preferred to perform only black box tests to reduce coupling between implementation and tests. 4. Support: extending a class without a contract/interface implies to perform some adaptations/checks (not so much in practice) simplified by previous tests But that's the topic ! 5. It's not possible currently to change l3 agent manager through configuration - so i must "develop" my own neutron-l3-agent binary implementation in order to allow providing a custom manager to main() - i must verify my binary was not erased during updates Awkward: 6. (un)deployment methods get the router RouterInfo using different strategies: - _router_added builds it and stores it in self.router_info cache - _router_removed get it from self.router_info cache - external_gateway/internal_network_added/removed get it through arguments 7._router_added and _process_routers have strange behaviours: - _process_routers calls _router_added will verifying to build router RouterInfo object - _router_added computes the router RouterInfo object and store it in self.router_info - _process_routers get it back from self.router_info IMHO, it seems more logical to let - _process_routers builds and stores router RouterInfo object and - _process_routers pass the object as an argument to _router_added The same might apply to _router_removed and _process_routers ? I must share with pcm about "L3 Vendor plugins" BPs to verify my understanding and possible synergies. But a priori [1] BP seems to be the only "synergy candidate". Cedric [1] https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation On Tue, Apr 22, 2014 at 6:18 PM, Carl Baldwin <[email protected]<mailto:[email protected]>> wrote: Cedric, I'm just getting back from a short vacation. Please excuse the delayed reply. I have a feeling that this subject may have been discussed in the past before I was very active in Neutron. So, others may chime in if I'm missing something. For the customizations that you're making, it sounds like some sort of hook system would work best. You are currently using inheritance to achieve it but I worry that the L3 agent class has not been designed for this inheritance and may not be entirely suitable for your needs. What has been your experience? Have you found it easy to maintain your subclass as the L3 agent evolves? If not, what problems have you seen? Are there parts of the agent design that made it difficult or awkward? I suspect that a well-designed and stable hook system will better suit your needs in the long run. However, nothing like that exists in the agent now. Is there some synergy here with the "L3 Vendor plugins" summit topic proposal [1]. Could you look through that proposal and the linked blueprints with that in mind? Carl [1] http://summit.openstack.org/cfp/details/81 On Fri, Apr 18, 2014 at 9:11 AM, zz elle <[email protected]<mailto:[email protected]>> wrote: > Hi everyone, > > > I would like to propose a change to simplify/allow l3 agent manager > customization 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 must of the time i must customize L3 agent behavior in order > to: > - add custom iptables rules in the router (on router/port post-deployment), > - remove custom iptables rules in the router (on port pre-undeployment), > - update router config through sysctl (on router post-deployment), > - start an application in the router (on router/port post-deployment), > - stop an application in the router (on router/port pre-undeployment), > - etc ... > Currently (Havana,Icehouse), i create my own L3 agent manager which extends > neutron one. > And I replace neutron-l3-agent binary, indeed it's not possible to > change/hook l3 agent manager implementation by configuration. > > > What would be the correct way to allow l3 agent manager customization ? > - Allow to specify l3 agent manager implementation through configuration > ==> like the option router_scheduler_driver which allows to change router > scheduler implementation > - Allow to hook l3 agent manager implementation > ==> like the generic hook system in nova (nova.hooks used in > nova.compute.api) > ==> or like the neutron ML2 mechanism hook system > (neutron.plugins.ml2.driver_api:MechanismDriver) > - Other idea ? > > > It seems the same question could be asked for the dhcp agent ? > > > Thanks, > > Cedric (zzelle@irc) > > > _______________________________________________ > OpenStack-dev mailing list > [email protected]<mailto:[email protected]> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
