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. 2) nova.utils This one is pretty easy. It uses import_object(), and there is an equivalent in openstack-common already. 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. 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. 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. 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. 6) nova.log I haven't looked at this yet. -- Russell Bryant _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
