Paul, I worked much of this in to my blueprint [1].



On Fri, Nov 21, 2014 at 11:48 AM, Paul Michali (pcm) <> wrote:
> Hi,
> I talked to Carl today to discuss the L3 agent restructuring and the change
> set I had published (, 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 (
> Regards,
> PCM (Paul Michali)
> MAIL …..….
> IRC ……..… pc_m (
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to