Open Stack

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141121/d8d0f802/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141121/d8d0f802/attachment-0001.pgp>