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
