Open Stack

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 <zzelle at gmail.com<mailto:zzelle at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: torsdag 24 april 2014 00:34
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
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 <carl at ecbaldwin.net<mailto:carl at ecbaldwin.net>> 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 <zzelle at gmail.com<mailto:zzelle at gmail.com>> 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 at irc)
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140429/426b8403/attachment.html>