<div><span style="font-size: 12px;"><span style="font-size: 13px; "><div><span style="font-size: 12px; ">I'd much prefer that we move all the nova.rpc into common. This will facilitate the use of the code in other projects and perhaps even third-party applications. The fact this code isn't reused elsewhere is largely be because it isn't reusable in its current state.</span></div><div><span style="font-size: 12px; "><br></span></div></span></span></div><div><span style="font-size: 12px;">For the ZeroMQ RPC driver, I'd rather that Glance/Nova can use the existing implementation, rather than having to develop and maintain a separate driver for the express purpose of supporting notifications. It is highly redundant. I'm sure Russell must feel the same way about maintaining two Qpid drivers.</span></div><div><span style="font-size: 12px;"><br></span></div><div>-- <br>Eric Windisch<div><br></div></div>
<p style="color: #A0A0A8;">On Tuesday, April 3, 2012 at 9:36 AM, Russell Bryant wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>Thanks for sharing this information. For the future, I think this type</div><div>of analysis and discussion is something that is great to have on the</div><div>mailing list instead of just a private group. I wish I had seen it sooner.</div><div><br></div><div>The code in nova.rpc seems useful enough that it very well may be used</div><div>elsewhere. I know it's more than what is needed for notifications, but</div><div>it does support what is needed for notifications (and more). I like the</div><div>idea of moving the whole thing instead of having separate messaging code</div><div>for just notifications.</div><div><br></div><div>-- </div><div>Russell Bryant</div><div><br></div><div>On 04/03/2012 09:20 AM, Swaminathan Venkataraman wrote:</div><blockquote type="cite"><div><div>Hi,</div><div>I'm actively working on the notification part. I did some analysis on</div><div>the code and dependencies and was planning to submit a blueprint by end</div><div>of the week. We can use that to finalize the interface for the</div><div>notification. The rpc implementation is rich (compared to just what we</div><div>need for notifications) because nova uses it for all rpc related</div><div>communications. The idea that I was working with was to just move what</div><div>we need for notifications. In that scenario we do not really need all of</div><div>rpc in openstack-common. If we do want a common implementation that all</div><div>openstack components can use to communicate the middleware, it might</div><div>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><br></div><div> *</div><div><br></div><div><br></div><div> ---------- Forwarded message ----------</div><div> From: *Swaminathan Venkataraman* <<a href="mailto:venkat.db@gmail.com">venkat.db@gmail.com</a></div><div> <<a href="mailto:venkat.db@gmail.com">mailto:venkat.db@gmail.com</a>>></div><div> Date: Mon, Mar 19, 2012 at 8:31 PM</div><div> Subject: Re: [Openstack] Notifiers</div><div> To: Monsyne Dragon <<a href="mailto:mdragon@rackspace.com">mdragon@rackspace.com</a></div><div> <<a href="mailto:mdragon@rackspace.com">mailto:mdragon@rackspace.com</a>>></div><div> Cc: Mark McLoughlin <markmc@redhat.com <<a href="mailto:markmc@redhat.com">mailto:markmc@redhat.com</a>>>,</div><div> Jason Kölker <<a href="mailto:jason.koelker@rackspace.com">jason.koelker@rackspace.com</a></div><div> <<a href="mailto:jason.koelker@rackspace.com">mailto:jason.koelker@rackspace.com</a>>>, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a></div><div> <<a href="mailto:jaypipes@gmail.com">mailto:jaypipes@gmail.com</a>>></div><div><br></div><div><br></div><div> I did some analysis on notifier and rpc in nova and there are a</div><div> bunch of dependencies that have to be sorted out before we can move</div><div> them to openstack-common. Here are some of the details.</div><div> </div><div> o notifier and rpc use flags, utils, logging, context, db,</div><div> exception, from nova.</div><div> o</div><div> o The modules in notfier and rpc use FLAGS from flags.py which is</div><div> an instance of NovaConfigOpts. They mainly use it to register</div><div> the config options and access them. Given that, it seems like we</div><div> could use CommonConfigOpts directly to register the options.</div><div> This will eliminate the dependency on flags and flagfile.</div><div> o</div><div> o There are three functions that are used from utils - utcnow,</div><div> import_object, and to_primitive. There is a utils in</div><div> openstack-common which already contains utcnow and</div><div> import_object. The code also macthes line to line with the</div><div> implementation in nova. The to_primitive function is missing in</div><div> openstack-common. One option could be to move this function</div><div> alone to openstack-common which should eliminate the dependency</div><div> on the nova based utils.</div><div> o</div><div> o notifier and api use log from nova. In fact they work with an</div><div> instance of NovaContextAdapter which in turn is an instance of</div><div> LoggerAdapter. NovaContextAdapter is used to pass the context,</div><div> the instance uuid, and the nova version to the logger. The</div><div> modules in openstack-common are using the python logging module</div><div> directly. So, if we need notifier to be able to print contextual</div><div> information we will have to add this functionality to</div><div> openstack-common.</div><div> o</div><div> o Both nova and openstack-common have an implementation of</div><div> RequestContext. The one in Nova is richer and both notifier and</div><div> rpc use functionality from RequestContext in nova. The other</div><div> difference is that the RequestContext in nova uses a weak</div><div> refernce store to save the context information. I did see a</div><div> couple of instances where the context information was deleted</div><div> from the store, but I'm not sure whether it is being accessed.</div><div> So, should the context in openstack-common be enhanced?</div><div> o</div><div> o db from nova is used only by capacity_notifier. It looks like it</div><div> sends events that are only related to compute manager events.</div><div> So, should this be part of openstack-common?</div><div> I've not looked at exception. I'll also have to look at rpc in more</div><div> detail. Please do let me know if this is the right direction.</div><div> </div><div> thanks,</div><div> Venkat</div><div><br></div><div>---------- Forwarded message ----------</div><div>From: *Mark McLoughlin* <markmc@redhat.com <<a href="mailto:markmc@redhat.com">mailto:markmc@redhat.com</a>>></div><div>Date: Tue, Mar 20, 2012 at 8:05 PM</div><div>Subject: Re: [Openstack] Notifiers</div><div>To: Swaminathan Venkataraman <<a href="mailto:venkat.db@gmail.com">venkat.db@gmail.com</a></div><div><<a href="mailto:venkat.db@gmail.com">mailto:venkat.db@gmail.com</a>>></div><div>Cc: Monsyne Dragon <<a href="mailto:mdragon@rackspace.com">mdragon@rackspace.com</a></div><div><<a href="mailto:mdragon@rackspace.com">mailto:mdragon@rackspace.com</a>>>, Jason Kölker</div><div><jason.koelker@rackspace.com <<a href="mailto:jason.koelker@rackspace.com">mailto:jason.koelker@rackspace.com</a>>>, Jay</div><div>Pipes <jaypipes@gmail.com <<a href="mailto:jaypipes@gmail.com">mailto:jaypipes@gmail.com</a>>></div><div><br></div><div>---------- Forwarded message ----------</div><div>From: *Mark McLoughlin* <markmc@redhat.com <<a href="mailto:markmc@redhat.com">mailto:markmc@redhat.com</a>>></div><div>Date: Tue, Mar 20, 2012 at 1:25 PM</div><div>Subject: Re: [Openstack] Notifiers</div><div>To: Swaminathan Venkataraman <<a href="mailto:venkat.db@gmail.com">venkat.db@gmail.com</a></div><div><<a href="mailto:venkat.db@gmail.com">mailto:venkat.db@gmail.com</a>>></div><div>Cc: Monsyne Dragon <<a href="mailto:mdragon@rackspace.com">mdragon@rackspace.com</a></div><div><<a href="mailto:mdragon@rackspace.com">mailto:mdragon@rackspace.com</a>>>, Jason Kölker</div><div><jason.koelker@rackspace.com <<a href="mailto:jason.koelker@rackspace.com">mailto:jason.koelker@rackspace.com</a>>>, Jay</div><div>Pipes <jaypipes@gmail.com <<a href="mailto:jaypipes@gmail.com">mailto:jaypipes@gmail.com</a>>></div><div><br></div><div><br></div><div>Hi Venkat,</div><div><br></div><div>Could you file a bug or blueprint against openstack-common with all this</div><div>great info?</div><div><br></div><div>Cheers,</div><div>Mark.</div><div><br></div><div>On Tue, 2012-03-20 at 19:37 +0530, Swaminathan Venkataraman wrote:</div><blockquote type="cite"><div><div>Sure Mark, but here is a bit more of analysis that I did. I'll file a</div><div>blueprint because I'm not sure if this is a bug.</div><div><br></div><div><br></div><div>There is an exception module defined in openstack-common. This has a</div><div>class named openstackException which is similar to NovaException and I</div><div>guess is to be subclassed to define exceptions that go in</div><div>openstack-common. openstack-common also defines a decorator for</div><div>wrapping methods to catch exceptions, but it does not try to send the</div><div>exception to the notification system like the one in nova.exception</div><div>does. Based on this we could use exceptions in openstack-common in</div><div>notifier and rpc. We'll still have to figure out what to do with</div><div>exceptions which are common (like ClassNotFoundexception). We'll have</div><div>to duplicate them or modules in nova will have to import two different</div><div>exception modules with different hierarchies, if we move common</div><div>exceptions to openstack-common. The ideal scenario is to have one</div><div>single hierarchy for exceptions, but I guess that this is a bigger</div><div>decision.</div></div></blockquote><div><br></div><div>Firstly, I wouldn't consider the openstack.common.exception as</div><div>particularly complete or final. I'd be happy for us to completely</div><div>re-think the approach to exceptions in openstack-common.</div><div><br></div><div>The wrap_exception() decorator could continue to live in nova for now.</div><div><br></div><div>exception.ClassNotFound is only raised by utils.import_object, but</div><div>openstack-common has its own version of that method and raises its own</div><div>exception.NotFound. So, no problem there.</div><div><br></div><div>I think its best to leave rabbit_notifier.py in nova for the moment.</div><div>Perhaps move it to the nova.rpc module.</div><div><br></div><blockquote type="cite"><div><div>The driver for notification is decided based on</div><div>FALGS.notification_driver. In the current scenario, since glance and</div><div>nova use different methods to do notifications, they can end up with</div><div>different drivers. If we do make the notifier common and if we want to</div><div>provide the capability for each of the openstack components to use</div><div>different drivers, we cannot just use the driver defined in the</div><div>configuration. One way is to pass the notifier as a parameter or</div><div>provide the configuration to be used to get the notifier and use</div><div>different configuration parameters for different components.</div></div></blockquote><div><br></div><div>I think we'll want the log, list, no-op and test notifiers in</div><div>openstack-common.</div><div><br></div><div>The way to handle configuration is to do what glance does - have a</div><div>Notifier class which accepts a ConfigOpts as a constructor parameter.</div><div>The class defines a "strategy" or "driver" option and loads the</div><div>appropriate driver based on that option.</div><div><br></div><div>IMHO, the best way to approach moving stuff like this to</div><div>openstack-common is to start with an (almost) fresh slate - don't be too</div><div>worried about what Nova or Glance currently does, but instead try and</div><div>define the best API to meet their requirements.</div><div><br></div><div>Cheers,</div><div>Mark.</div></div></blockquote><div><br></div><div>_______________________________________________</div><div>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a></div><div>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a></div><div>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a></div><div>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>