openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

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.