Hi,<div>I'm actively working on the notification part. I did some analysis on the code and dependencies and was planning to submit a blueprint by end of the week. We can use that to finalize the interface for the notification. The rpc implementation is rich (compared to just what we need for notifications) because nova uses it for all rpc related communications. The idea that I was working with was to just move what we need for notifications. In that scenario we do not really need all of rpc in openstack-common. If we do want a common implementation that all openstack components can use to communicate the middleware, it might make to sense to move the whole of rpc to openstack-common. </div>
<div><br></div><div>Thoughts?</div><div><br></div><div><br></div><div>Anyways, here is the analysis and some of the comments I got...</div><div><br></div><div>Cheers,</div><div>Venkat</div><div><ul style><li style="margin-left:15px">
<br><div class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial;font-size:small">---------- Forwarded message ----------</span><br style="color:rgb(0,0,0);font-family:arial;font-size:small">
<span style="color:rgb(0,0,0);font-family:arial;font-size:small">From: </span><b class="gmail_sendername" style="color:rgb(0,0,0);font-family:arial;font-size:small">Swaminathan Venkataraman</b><span style="color:rgb(0,0,0);font-family:arial;font-size:small"> </span><span dir="ltr" style="color:rgb(0,0,0);font-family:arial;font-size:small"><<a href="mailto:venkat.db@gmail.com">venkat.db@gmail.com</a>></span><br style="color:rgb(0,0,0);font-family:arial;font-size:small">
<span style="color:rgb(0,0,0);font-family:arial;font-size:small">Date: Mon, Mar 19, 2012 at 8:31 PM</span><br style="color:rgb(0,0,0);font-family:arial;font-size:small"><span style="color:rgb(0,0,0);font-family:arial;font-size:small">Subject: Re: [Openstack] Notifiers</span><br style="color:rgb(0,0,0);font-family:arial;font-size:small">
<span style="color:rgb(0,0,0);font-family:arial;font-size:small">To: Monsyne Dragon <<a href="mailto:mdragon@rackspace.com">mdragon@rackspace.com</a>></span><br style="color:rgb(0,0,0);font-family:arial;font-size:small">
<span style="color:rgb(0,0,0);font-family:arial;font-size:small">Cc: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>>, Jason Kölker <<a href="mailto:jason.koelker@rackspace.com">jason.koelker@rackspace.com</a>>, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>></span><br style="color:rgb(0,0,0);font-family:arial;font-size:small">
<br style="color:rgb(0,0,0);font-family:arial;font-size:small"><br style="color:rgb(0,0,0);font-family:arial;font-size:small"><span lang="" style="color:rgb(0,0,0);font-family:arial;font-size:small"><div>I did some analysis on notifier and rpc in nova and there are a bunch of dependencies that have to be sorted out before we can move them to openstack-common. Here are some of the details.</div>
<div> </div><ul><li>notifier and rpc use flags, utils, logging, context, db, exception, from nova.</li><li></li><li>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, it seems like we could use CommonConfigOpts directly to register the options. This will eliminate the dependency on flags and flagfile.</li>
<li></li><li>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. One option could be to move this function alone to openstack-common which should eliminate the dependency on the nova based utils.</li>
<li></li><li>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 are using 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.</li>
<li></li><li>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 refernce store to save the context information. I did see a couple of instances where the context information was deleted from the store, but I'm not sure whether it is being accessed. So, should the context in openstack-common be enhanced?</li>
<li></li><li>db from nova is used only by capacity_notifier. It looks like it sends events that are only related to compute manager events. So, should this be part of openstack-common?</li></ul><div>I've not looked at exception. I'll also have to look at rpc in more detail. Please do let me know if this is the right direction.</div>
<div> </div><div>thanks,</div><div>Venkat</div></span><div class="HOEnZb" style="color:rgb(0,0,0);font-family:arial;font-size:small"><div class="h5"></div></div></div></li></ul></div><div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername">Mark McLoughlin</b> <span dir="ltr"><<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>></span><br>Date: Tue, Mar 20, 2012 at 8:05 PM<br>Subject: Re: [Openstack] Notifiers<br>
To: Swaminathan Venkataraman <<a href="mailto:venkat.db@gmail.com">venkat.db@gmail.com</a>><br>Cc: Monsyne Dragon <<a href="mailto:mdragon@rackspace.com">mdragon@rackspace.com</a>>, Jason Kölker <<a href="mailto:jason.koelker@rackspace.com">jason.koelker@rackspace.com</a>>, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>><br>
<br>---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Mark McLoughlin</b> <span dir="ltr"><<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>></span><br>Date: Tue, Mar 20, 2012 at 1:25 PM<br>
Subject: Re: [Openstack] Notifiers<br>To: Swaminathan Venkataraman <<a href="mailto:venkat.db@gmail.com">venkat.db@gmail.com</a>><br>Cc: Monsyne Dragon <<a href="mailto:mdragon@rackspace.com">mdragon@rackspace.com</a>>, Jason Kölker <<a href="mailto:jason.koelker@rackspace.com">jason.koelker@rackspace.com</a>>, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>><br>
<br><br>Hi Venkat,<br><br>Could you file a bug or blueprint against openstack-common with all this<br>great info?<br><br>Cheers,<br>Mark.</div><div class="gmail_quote"><br><div class="im">On Tue, 2012-03-20 at 19:37 +0530, Swaminathan Venkataraman wrote:<br>

> Sure Mark, but here is a bit more of analysis that I did. I'll file a<br>
> blueprint because I'm not sure if this is a bug.<br>
><br>
><br>
> There is an exception module defined in openstack-common. This has a<br>
> class named openstackException which is similar to NovaException and I<br>
> guess is to be subclassed to define exceptions that go in<br>
> openstack-common. openstack-common also defines a decorator for<br>
> wrapping  methods to catch exceptions, but it does not try to send the<br>
> exception to the notification system like the one in nova.exception<br>
> does. Based on this we could use exceptions in openstack-common in<br>
> notifier and rpc. We'll still have to figure out what to do with<br>
> exceptions which are common (like ClassNotFoundexception). We'll have<br>
> to duplicate them or modules in nova will have to import two different<br>
> exception modules with different hierarchies, if we move common<br>
> exceptions to openstack-common. The ideal scenario is to have one<br>
> single hierarchy for exceptions, but I guess that this is a bigger<br>
> decision.<br>
<br>
</div>Firstly, I wouldn't consider the openstack.common.exception as<br>
particularly complete or final. I'd be happy for us to completely<br>
re-think the approach to exceptions in openstack-common.<br>
<br>
The wrap_exception() decorator could continue to live in nova for now.<br>
<br>
exception.ClassNotFound is only raised by utils.import_object, but<br>
openstack-common has its own version of that method and raises its own<br>
exception.NotFound. So, no problem there.<br>
<br>
I think its best to leave rabbit_notifier.py in nova for the moment.<br>
Perhaps move it to the nova.rpc module.<br>
<div class="im"><br>
> The driver for notification is decided based on<br>
> FALGS.notification_driver. In the current scenario, since glance and<br>
> nova use different methods to do notifications, they can end up with<br>
> different drivers. If we do make the notifier common and if we want to<br>
> provide the capability for each of the openstack components to use<br>
> different drivers, we cannot just use the driver defined in the<br>
> configuration. One way is to pass the notifier as a parameter or<br>
> provide the configuration to be used to get the notifier and use<br>
> different configuration parameters for different components.<br>
<br>
</div>I think we'll want the log, list, no-op and test notifiers in<br>
openstack-common.<br>
<br>
The way to handle configuration is to do what glance does - have a<br>
Notifier class which accepts a ConfigOpts as a constructor parameter.<br>
The class defines a "strategy" or "driver" option and loads the<br>
appropriate driver based on that option.<br>
<br>
IMHO, the best way to approach moving stuff like this to<br>
openstack-common is to start with an (almost) fresh slate - don't be too<br>
worried about what Nova or Glance currently does, but instead try and<br>
define the best API to meet their requirements.<br>
<br>
Cheers,<br>
Mark.<br>
<br>
<br>
</div><br>