Paul, I worked much of this in to my blueprint [1].
Carl
[1]
https://review.openstack.org/#/c/131535/4/specs/kilo/restructure-l3-agent.rst
On Fri, Nov 21, 2014 at 11:48 AM, Paul Michali (pcm) p...@cisco.com wrote:
Hi,
I talked to Carl today to discuss the L3 agent restructuring and the change
set I had published (https://review.openstack.org/#/c/135392/), which was
trying to identify/exposing what is needed for the loading of device drivers
and the variation therein. I wasn’t sure how we’d do the separation of the
agents and wanted to discuss the options and brainstorm on some ideas on how
to do this.
We had a very good talk and here are some notes of what we were thinking
(Carl, chime in, if I missed anything or I’m interpreting them differently):
First step could be to create a service abstract class, and then child
classes for the various services to use these as “observers/subscribers” to
the L3 agent. The base class would have no-operation methods for each action
that the L3 agent could notify about, and the child classes could (later)
hold service specific logic. The base class would include a “register”
method, so that a service can register for notification from the L3 agent
(mapping to these methods created). The child classes would do service
specific loading of device drivers.
Currently, the L3 agent (and VPN agent) load the device drivers for
services. What can be done in this first step, is, instead of doing the
load, a service object can be created. This object would do the loading and
register with the L3 agent for notifications.
Second step could be to populate the child services’ notification handlers,
for any methods of interest to those services. Involves taking methods that
are in the various agent classes and move them into the new service child
classes, and adapt as needed.
Third step could be to create a abstract factory (or factory method), which
the L3 agent would call at startup, instead of it creating the service
instances. This factory would determine what services are enabled (one way
is to see if service_provider config entry for the service type), and then
create the service instance, which in turn would load the device driver and
register with the L3 agent. This way, the L3 agent no longer knows about the
services.
This would imply no longer having separate VPN agent process, and instead,
all the service instances would be created by the factory. It would change
the way DevStack would start up things (e.g. only starting up the L3 agent
process).
Fourth step (optional) could be to create new config file entries so that a
common device driver loader could be created, instead of service specific
loaders. This is more of a post refactor cleanup activity.
Some other thoughts:
Should strive to keep the config and start-up the same initially (and as
much as possible).
Initially, the services will get an L3 agent passed in on create, but in the
future, a router instance can be provided to the service.
Using ABC for observer, so that services only have to implement the desired
methods of interest.
Thoughts were to do notification handlers (step 2) before factory (step 3),
so that service is extracted, before changing startup.
Hope that gives an idea of what we were thinking about for this chinese
finger puzzle (https://www.youtube.com/watch?v=k8BSiyDs0nw)
Regards,
PCM (Paul Michali)
MAIL …..…. p...@cisco.com
IRC ……..… pc_m (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
