openstack team mailing list archive

[Russell Bryant <rbryant@xxxxxxxxxx>]

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