Open Stack

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> 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> 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
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20140424/3a61d556/attachment.html>