On Tue, 2012-04-03 at 11:00 -0400, Russell Bryant wrote: > On 04/03/2012 10:38 AM, Mark McLoughlin wrote: > > Hey Russell, > > > > On Mon, 2012-04-02 at 16:26 -0400, Russell Bryant wrote: > >> Greetings, > >> > >> There was a thread on this list a little while ago about moving the > >> notification drivers that are in nova and glance into openstack.common > >> since they provide very similar functionality, but have implementations > >> that have diverged over time. Is anyone actively working on this? If > >> so, please let me know. > >> > >> For the message queue notifiers, nova uses nova.rpc to do the heavy > >> lifting. Glance has notifiers written against the messaging libs > >> directly. I think it makes sense to take the nova approach. This would > >> mean moving nova.rpc into openstack.common before the notifiers can get > >> moved. > >> > >> I have started looking at moving nova.rpc to openstack.common.rpc. My > >> plan is: > >> > >> 1) Write a series of patches that reduces coupling in nova.rpc on the > >> rest of nova. > >> > >> 2) Submit changes needed to support this decoupling to openstack.common. > >> > >> 3) Once nova.rpc is sufficiently decoupled, move it to openstack.common. > >> > >> While doing the above, I want to aim for the least amount of disruption > >> to the rpc interface as is practical. > > > > That looks like a good plan. Have you got a rough idea already what > > needs to happen for (2) in openstack-common? > > Roughly ... it's a matter of going through all of the nova imports and > ensuring there are openstack-common equivalents. I don't think much new > is needed in openstack-common. > > nova.rpc depenencies on other bits of nova include: > > 1) nova.flags > > Configuration handling needs to be refactored in nova.rpc so that a > config object can get passed in. I don't see any openstack-common > changes needed here.
Yep. > 2) nova.utils > > This one is pretty easy. It uses import_object(), and there is an > equivalent in openstack-common already. Cool. > 3) nova.local > > This looks like a good candidate for moving to openstack-common and > switching all usage of nova.local to be openstack.common.local. Well, what do you know? http://review.openstack.org/5464 > 4) nova.exception > > nova.rpc defines two exceptions based on NovaException. They could be > based on OpenstackException from openstack-common, instead. There's > also an RPC exception defined in nova.exception, but that can be moved > into nova.rpc with the others. Is there any great value to having a base Exception class? e.g. a cfg exception and an rpc exception are completely unrelated, so I'd just have those modules define unrelated exceptions > The code also uses wrap_exception. The one in openstack-common seems > sufficient for how it's used. > > However, I'm not sure how people would feel about having both > openstack.common.exception and nova.exception in the tree since they > overlap quite a bit. I like being able to do work in pieces, but having > them both in the tree leaves the code in an odd state, so we need some > end goal in mind. I'm not a huge fan of openstack.common.exception > 5) nova.context > > I haven't looked at this one in detail, yet. We'll have to sort out > what to do with RequestContext. I see in the message from Swaminathan > Venkataraman that both openstack-common and nova have RequestContext, > but there's more code in the nova version. I suppose we should look at > making the openstack-common version sufficient for nova and then switch > nova to it. I'd actually start by trying to figure out how to avoid passing a RequestContext to the rpc code - it seems like a WSGI request handling related object and the rpc code shouldn't need to rely on something like that. I can't quickly figure out what it uses it for. Do you know? > 6) nova.log > > I haven't looked at this yet. Adding common logging code to openstack-common is definitely on the roadmap, but you probably don't want to get ratholed by it. Cheers, Mark. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
