Open Stack

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) <pcm at 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 …..…. pcm at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>