Difference between revisions of "Notifier-in-openstack-common"
m |
|||
| Line 1: | Line 1: | ||
| − | |||
* '''Launchpad Entry''': notifier-in-openstack-common | * '''Launchpad Entry''': notifier-in-openstack-common | ||
* '''Created''': 06 Apr 2012 | * '''Created''': 06 Apr 2012 | ||
| Line 26: | Line 25: | ||
== Design == | == Design == | ||
| − | [[Image: | + | [[Image:Notifier.png]] |
As shown in the class diagram, the notifier will use a specific strategy based on the configuration to send the notifications. The constructor will be passed in a configuration object which will be used by the strategies to read in the relevant information. | As shown in the class diagram, the notifier will use a specific strategy based on the configuration to send the notifications. The constructor will be passed in a configuration object which will be used by the strategies to read in the relevant information. | ||
Revision as of 21:30, 16 February 2013
- Launchpad Entry: notifier-in-openstack-common
- Created: 06 Apr 2012
- Contributors:
Contents
Summary
Currently both glance and nova have separate notifier modules to take care of notifications. Both Nova and glance also have similar design where they use a common interface to send notifications and have specific implementations to handle log,rabbit,list, and no-op notifications. The intent here is to move the notifier module to openstack-common so that nova and glance can use the same code base. Here are the steps, at a high level, to get this done.
1. Decide on a common interface for notifications
2. Move code to openstack-common
3. Change code in nova and glance to use openstack-common for the notifications
Release Note
Rationale
This will help in eliminating duplicate code and code reuse.
User stories
Assumptions
Design
As shown in the class diagram, the notifier will use a specific strategy based on the configuration to send the notifications. The constructor will be passed in a configuration object which will be used by the strategies to read in the relevant information.
Implementation
The plan is to reuse most of the code that currently exists in the nova notifier module. Here is some analysis of the existing code and the dependencies.
- notifier and rpc use flags, utils, logging, context, db, exception, from nova. The modules in notfier and rpc use FLAGS from flags.py which is an instance of NovaConfigOpts. They mainly use it to register the config options and access them. Given that we could use CommonConfigOpts directly to register the options. This will eliminate the dependency on flags and flag file.
- There are three functions that are used from utils - utcnow, import_object, and to_primitive. There is a utils in openstack-common which already contains utcnow and import_object. The code also macthes line to line with the implementation in nova. The to_primitive function is missing in openstack-common. This function can be moved to openstack-common which should eliminate the dependency on the nova based utils.
- notifier and api use log from nova. In fact they work with an instance of NovaContextAdapter which in turn is an instance of LoggerAdapter. NovaContextAdapter is used to pass the context, the instance uuid, and the nova version to the logger. The modules in openstack-common use the python logging module directly. So, if we need notifier to be able to print contextual information we will have to add this functionality to openstack-common.
- Both nova and openstack-common have an implementation of RequestContext. The one in Nova is richer and both notifier and rpc use functionality from RequestContext in nova. The other difference is that the RequestContext in nova uses a weak reference store to save the context information. There are couple of instances where the context information is deleted from the store, but there aren't any where the store is being accessed. There is already an implementation of local in openstack-common (http://review.openstack.org/5464) which should make this easier.
- db from nova is used only by capacity_notifier. It sends events that are only related to compute manager events. It might make sense to keep the capacity notifier in nova.
The notifier in nova uses nova specific exception and these will be changed to use exceptions from openstack-common.
