Re: [Openstack] Moving nova.rpc into openstack.common
On 05/07/2012 04:08 PM, Russell Bryant wrote: On 05/07/2012 03:40 PM, Doug Hellmann wrote: The metering project will probably want to take advantage of this work. How far along is it, and how can we help? I can speak to the nova.rpc part, at least. I've been working on it some with hopes of having it done by folsom-1. I would be happy to have help on it, though, as I have some other things I'm working on at the same time. Take a look at nova/rpc/*.py. Anywhere you see an import from nova that isn't nova.openstack.common is a dependency on nova that must be removed before the code can move to openstack-common. Another thing that would be useful is providing feedback on this feature branch: https://github.com/russellb/nova/tree/bp/versioned-rpc-apis which is for this blueprint: https://blueprints.launchpad.net/nova/+spec/versioned-rpc-apis I'd like to get this finished before moving rpc to openstack-common, since I would hope that all new usage of rpc would use versioned APIs. -- 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
Re: [Openstack] Moving nova.rpc into openstack.common
The metering project will probably want to take advantage of this work. How far along is it, and how can we help? On Fri, Apr 6, 2012 at 6:56 AM, Swaminathan Venkataraman venkat...@gmail.com wrote: Hi, I've created a blueprint for this. Please take a look and let me know your comments. https://blueprints.launchpad.net/openstack-common/+spec/notifier thanks, Venkat On Tue, Apr 3, 2012 at 11:13 PM, Jay Pipes jaypi...@gmail.com wrote: On 04/03/2012 01:40 PM, John Garbutt wrote: 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 Yeah, I don't see too much value in having everything inherit from a common exception base class. I think the different projects will typically want to customize the error message text... My vote would be to have some handy mix-ins in openstack.common, if that works for everyone Sure, that would work... -jay __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
On Apr 3, 2012, at 8:00 AM, Russell Bryant wrote: […] 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. Yeah, this one might be kind of weird, because it's used to set the 'nova context', and I'm not sure it actually applies to Openstack generically. […] 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. Hm. I wonder if we need some sort of serialize/deserialize callbacks or something so that nova can encode/decode the context that's passed… and not have any of this context stuff be a part of openstack-common. Just a random thought without looking or thinking about it too much. :) […] - Chris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
Hi, I've created a blueprint for this. Please take a look and let me know your comments. https://blueprints.launchpad.net/openstack-common/+spec/notifier thanks, Venkat On Tue, Apr 3, 2012 at 11:13 PM, Jay Pipes jaypi...@gmail.com wrote: On 04/03/2012 01:40 PM, John Garbutt wrote: 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 Yeah, I don't see too much value in having everything inherit from a common exception base class. I think the different projects will typically want to customize the error message text... My vote would be to have some handy mix-ins in openstack.common, if that works for everyone Sure, that would work... -jay __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
+1 for move to nova.common I remember discussion about versioning these messages to aid rolling / zero-downtime upgrades. Might be worth considering those when doing the decoupling? Cheers, John -Original Message- From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf Of Chris Behrens Sent: 02 April 2012 23:53 To: Russell Bryant Cc: Duncan McGreggor; openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Moving nova.rpc into openstack.common Awesome, thanks :) On Apr 2, 2012, at 3:46 PM, Russell Bryant wrote: I just threw up a patch a little while ago: https://review.openstack.org/6119 -- Russell Bryant On 04/02/2012 06:37 PM, Chris Behrens wrote: Seems like a sensible plan. Carrot can go now. I marked it deprecated so we can remove in folsom. I can take care of this today, even. On Apr 2, 2012, at 3:02 PM, Duncan McGreggor dun...@dreamhost.com wrote: +1 Thanks for exploring this, Russell! Next step: getting a common REST API abstraction in place that all the projects can use... ;-) d On Mon, Apr 2, 2012 at 4:26 PM, Russell Bryant rbry...@redhat.com 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. While we're at it, is it time to drop nova.rpc.impl_carrot? It is marked as deprecated in Essex. Is there any reason anyone would still use impl_carrot over impl_kombu? Thoughts? Thanks, -- 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
Russell Bryant wrote: I proposed a session to discuss this a bit at the summit: http://summit.openstack.org/sessions/view/95 There are a lot of ways this could be approached. I'm going to try to write up a proposal at some point to get a discussion moving. Note that there is also the following discussion: http://summit.openstack.org/sessions/view/39 which was folded into amore generic openstack-common plans session: http://summit.openstack.org/sessions/view/28 -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
Hi, I'm actively working on the notification part. I did some analysis on the code and dependencies and was planning to submit a blueprint by end of the week. We can use that to finalize the interface for the notification. The rpc implementation is rich (compared to just what we need for notifications) because nova uses it for all rpc related communications. The idea that I was working with was to just move what we need for notifications. In that scenario we do not really need all of rpc in openstack-common. If we do want a common implementation that all openstack components can use to communicate the middleware, it might make to sense to move the whole of rpc to openstack-common. Thoughts? Anyways, here is the analysis and some of the comments I got... Cheers, Venkat - -- Forwarded message -- From: Swaminathan Venkataraman venkat...@gmail.com Date: Mon, Mar 19, 2012 at 8:31 PM Subject: Re: [Openstack] Notifiers To: Monsyne Dragon mdra...@rackspace.com Cc: Mark McLoughlin mar...@redhat.com, Jason Kölker jason.koel...@rackspace.com, Jay Pipes jaypi...@gmail.com I did some analysis on notifier and rpc in nova and there are a bunch of dependencies that have to be sorted out before we can move them to openstack-common. Here are some of the details. - notifier and rpc use flags, utils, logging, context, db, exception, from nova. - - The modules in notfier and rpc use FLAGS from flags.py which is an instance of NovaConfigOpts. They mainly use it to register the config options and access them. Given that, it seems like we could use CommonConfigOpts directly to register the options. This will eliminate the dependency on flags and flagfile. - - There are three functions that are used from utils - utcnow, import_object, and to_primitive. There is a utils in openstack-common which already contains utcnow and import_object. The code also macthes line to line with the implementation in nova. The to_primitive function is missing in openstack-common. One option could be to move this function alone to openstack-common which should eliminate the dependency on the nova based utils. - - notifier and api use log from nova. In fact they work with an instance of NovaContextAdapter which in turn is an instance of LoggerAdapter. NovaContextAdapter is used to pass the context, the instance uuid, and the nova version to the logger. The modules in openstack-common are using the python logging module directly. So, if we need notifier to be able to print contextual information we will have to add this functionality to openstack-common. - - Both nova and openstack-common have an implementation of RequestContext. The one in Nova is richer and both notifier and rpc use functionality from RequestContext in nova. The other difference is that the RequestContext in nova uses a weak refernce store to save the context information. I did see a couple of instances where the context information was deleted from the store, but I'm not sure whether it is being accessed. So, should the context in openstack-common be enhanced? - - db from nova is used only by capacity_notifier. It looks like it sends events that are only related to compute manager events. So, should this be part of openstack-common? I've not looked at exception. I'll also have to look at rpc in more detail. Please do let me know if this is the right direction. thanks, Venkat -- Forwarded message -- From: Mark McLoughlin mar...@redhat.com Date: Tue, Mar 20, 2012 at 8:05 PM Subject: Re: [Openstack] Notifiers To: Swaminathan Venkataraman venkat...@gmail.com Cc: Monsyne Dragon mdra...@rackspace.com, Jason Kölker jason.koel...@rackspace.com, Jay Pipes jaypi...@gmail.com -- Forwarded message -- From: Mark McLoughlin mar...@redhat.com Date: Tue, Mar 20, 2012 at 1:25 PM Subject: Re: [Openstack] Notifiers To: Swaminathan Venkataraman venkat...@gmail.com Cc: Monsyne Dragon mdra...@rackspace.com, Jason Kölker jason.koel...@rackspace.com, Jay Pipes jaypi...@gmail.com Hi Venkat, Could you file a bug or blueprint against openstack-common with all this great info? Cheers, Mark. On Tue, 2012-03-20 at 19:37 +0530, Swaminathan Venkataraman wrote: Sure Mark, but here is a bit more of analysis that I did. I'll file a blueprint because I'm not sure if this is a bug. There is an exception module defined in openstack-common. This has a class named openstackException which is similar to NovaException and I guess is to be subclassed to define exceptions that go in openstack-common. openstack-common also defines a decorator for wrapping methods to catch exceptions, but it does not try to send the exception to the notification system like the one in nova.exception does. Based on
Re: [Openstack] Moving nova.rpc into openstack.common
Hi, I'm actively working on the notification part. I did some analysis on the code and dependencies and was planning to submit a blueprint by end of the week. We can use that to finalize the interface for the notification. The rpc implementation is rich (compared to just what we need for notifications) because nova uses it for all rpc related communications. The idea that I was working with was to just move what we need for notifications. In that scenario we do not really need all of rpc in openstack-common. If we do want a common implementation that all openstack components can use to communicate the middleware, it might make to sense to move the whole of rpc to openstack-common. Thoughts? Anyways, here is the analysis and some of the comments I got... Cheers, Venkat - -- Forwarded message -- From: Swaminathan Venkataraman venkat...@gmail.com Date: Mon, Mar 19, 2012 at 8:31 PM Subject: Re: [Openstack] Notifiers To: Monsyne Dragon mdra...@rackspace.com Cc: Mark McLoughlin mar...@redhat.com, Jason Kölker jason.koel...@rackspace.com, Jay Pipes jaypi...@gmail.com I did some analysis on notifier and rpc in nova and there are a bunch of dependencies that have to be sorted out before we can move them to openstack-common. Here are some of the details. - notifier and rpc use flags, utils, logging, context, db, exception, from nova. - - The modules in notfier and rpc use FLAGS from flags.py which is an instance of NovaConfigOpts. They mainly use it to register the config options and access them. Given that, it seems like we could use CommonConfigOpts directly to register the options. This will eliminate the dependency on flags and flagfile. - - There are three functions that are used from utils - utcnow, import_object, and to_primitive. There is a utils in openstack-common which already contains utcnow and import_object. The code also macthes line to line with the implementation in nova. The to_primitive function is missing in openstack-common. One option could be to move this function alone to openstack-common which should eliminate the dependency on the nova based utils. - - notifier and api use log from nova. In fact they work with an instance of NovaContextAdapter which in turn is an instance of LoggerAdapter. NovaContextAdapter is used to pass the context, the instance uuid, and the nova version to the logger. The modules in openstack-common are using the python logging module directly. So, if we need notifier to be able to print contextual information we will have to add this functionality to openstack-common. - - Both nova and openstack-common have an implementation of RequestContext. The one in Nova is richer and both notifier and rpc use functionality from RequestContext in nova. The other difference is that the RequestContext in nova uses a weak refernce store to save the context information. I did see a couple of instances where the context information was deleted from the store, but I'm not sure whether it is being accessed. So, should the context in openstack-common be enhanced? - - db from nova is used only by capacity_notifier. It looks like it sends events that are only related to compute manager events. So, should this be part of openstack-common? I've not looked at exception. I'll also have to look at rpc in more detail. Please do let me know if this is the right direction. thanks, Venkat -- Forwarded message -- From: Mark McLoughlin mar...@redhat.com Date: Tue, Mar 20, 2012 at 8:05 PM Subject: Re: [Openstack] Notifiers To: Swaminathan Venkataraman venkat...@gmail.com Cc: Monsyne Dragon mdra...@rackspace.com, Jason Kölker jason.koel...@rackspace.com, Jay Pipes jaypi...@gmail.com -- Forwarded message -- From: Mark McLoughlin mar...@redhat.com Date: Tue, Mar 20, 2012 at 1:25 PM Subject: Re: [Openstack] Notifiers To: Swaminathan Venkataraman venkat...@gmail.com Cc: Monsyne Dragon mdra...@rackspace.com, Jason Kölker jason.koel...@rackspace.com, Jay Pipes jaypi...@gmail.com Hi Venkat, Could you file a bug or blueprint against openstack-common with all this great info? Cheers, Mark. On Tue, 2012-03-20 at 19:37 +0530, Swaminathan Venkataraman wrote: Sure Mark, but here is a bit more of analysis that I did. I'll file a blueprint because I'm not sure if this is a bug. There is an exception module defined in openstack-common. This has a class named openstackException which is similar to NovaException and I guess is to be subclassed to define exceptions that go in openstack-common. openstack-common also defines a decorator for wrapping methods to catch exceptions, but it does not try to send the exception to the notification system like the one in nova.exception does. Based on
Re: [Openstack] Moving nova.rpc into openstack.common
Thanks for sharing this information. For the future, I think this type of analysis and discussion is something that is great to have on the mailing list instead of just a private group. I wish I had seen it sooner. The code in nova.rpc seems useful enough that it very well may be used elsewhere. I know it's more than what is needed for notifications, but it does support what is needed for notifications (and more). I like the idea of moving the whole thing instead of having separate messaging code for just notifications. -- Russell Bryant On 04/03/2012 09:20 AM, Swaminathan Venkataraman wrote: Hi, I'm actively working on the notification part. I did some analysis on the code and dependencies and was planning to submit a blueprint by end of the week. We can use that to finalize the interface for the notification. The rpc implementation is rich (compared to just what we need for notifications) because nova uses it for all rpc related communications. The idea that I was working with was to just move what we need for notifications. In that scenario we do not really need all of rpc in openstack-common. If we do want a common implementation that all openstack components can use to communicate the middleware, it might make to sense to move the whole of rpc to openstack-common. Thoughts? Anyways, here is the analysis and some of the comments I got... Cheers, Venkat * -- Forwarded message -- From: *Swaminathan Venkataraman* venkat...@gmail.com mailto:venkat...@gmail.com Date: Mon, Mar 19, 2012 at 8:31 PM Subject: Re: [Openstack] Notifiers To: Monsyne Dragon mdra...@rackspace.com mailto:mdra...@rackspace.com Cc: Mark McLoughlin mar...@redhat.com mailto:mar...@redhat.com, Jason Kölker jason.koel...@rackspace.com mailto:jason.koel...@rackspace.com, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com I did some analysis on notifier and rpc in nova and there are a bunch of dependencies that have to be sorted out before we can move them to openstack-common. Here are some of the details. o notifier and rpc use flags, utils, logging, context, db, exception, from nova. o o The modules in notfier and rpc use FLAGS from flags.py which is an instance of NovaConfigOpts. They mainly use it to register the config options and access them. Given that, it seems like we could use CommonConfigOpts directly to register the options. This will eliminate the dependency on flags and flagfile. o o There are three functions that are used from utils - utcnow, import_object, and to_primitive. There is a utils in openstack-common which already contains utcnow and import_object. The code also macthes line to line with the implementation in nova. The to_primitive function is missing in openstack-common. One option could be to move this function alone to openstack-common which should eliminate the dependency on the nova based utils. o o notifier and api use log from nova. In fact they work with an instance of NovaContextAdapter which in turn is an instance of LoggerAdapter. NovaContextAdapter is used to pass the context, the instance uuid, and the nova version to the logger. The modules in openstack-common are using the python logging module directly. So, if we need notifier to be able to print contextual information we will have to add this functionality to openstack-common. o o Both nova and openstack-common have an implementation of RequestContext. The one in Nova is richer and both notifier and rpc use functionality from RequestContext in nova. The other difference is that the RequestContext in nova uses a weak refernce store to save the context information. I did see a couple of instances where the context information was deleted from the store, but I'm not sure whether it is being accessed. So, should the context in openstack-common be enhanced? o o db from nova is used only by capacity_notifier. It looks like it sends events that are only related to compute manager events. So, should this be part of openstack-common? I've not looked at exception. I'll also have to look at rpc in more detail. Please do let me know if this is the right direction. thanks, Venkat -- Forwarded message -- From: *Mark McLoughlin* mar...@redhat.com mailto:mar...@redhat.com Date: Tue, Mar 20, 2012 at 8:05 PM Subject: Re: [Openstack] Notifiers To: Swaminathan Venkataraman venkat...@gmail.com mailto:venkat...@gmail.com Cc: Monsyne Dragon mdra...@rackspace.com mailto:mdra...@rackspace.com, Jason Kölker jason.koel...@rackspace.com
Re: [Openstack] Moving nova.rpc into openstack.common
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? 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
Re: [Openstack] Moving nova.rpc into openstack.common
On 04/03/2012 09:36 AM, Russell Bryant wrote: Thanks for sharing this information. For the future, I think this type of analysis and discussion is something that is great to have on the mailing list instead of just a private group. I wish I had seen it sooner. In Venkat's defense, I believe he did reach out originally to the mailing list on this topic: https://lists.launchpad.net/openstack/msg08539.html Agree that it's always good to have more analysis in a public forum, but Venkat did havejust start contributing, so we can give him a break I think! :) Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
On 04/03/2012 11:16 AM, Mark McLoughlin wrote: 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 Yeah, I don't see too much value in having everything inherit from a common exception base class. I think the different projects will typically want to customize the error message text... 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. Glance also has a different RequestContext: https://github.com/openstack/glance/blob/master/glance/common/context.py I wouldn't mind if the Glance-specific RequestContext inherited from a base openstack-common one, though, and just added its stuff related to Glance's owner_is_tenant config option Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
On 04/03/2012 12:23 PM, Jay Pipes wrote: On 04/03/2012 09:36 AM, Russell Bryant wrote: Thanks for sharing this information. For the future, I think this type of analysis and discussion is something that is great to have on the mailing list instead of just a private group. I wish I had seen it sooner. In Venkat's defense, I believe he did reach out originally to the mailing list on this topic: https://lists.launchpad.net/openstack/msg08539.html Agree that it's always good to have more analysis in a public forum, but Venkat did havejust start contributing, so we can give him a break I think! :) Yep. I didn't mean for that to come off in a negative way, so sorry about that. I did see the thread. It wasn't clear that anyone was actively working on it, though. -- 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
Re: [Openstack] Moving nova.rpc into openstack.common
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 Yeah, I don't see too much value in having everything inherit from a common exception base class. I think the different projects will typically want to customize the error message text... My vote would be to have some handy mix-ins in openstack.common, if that works for everyone ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
On 04/03/2012 01:40 PM, John Garbutt wrote: 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 Yeah, I don't see too much value in having everything inherit from a common exception base class. I think the different projects will typically want to customize the error message text... My vote would be to have some handy mix-ins in openstack.common, if that works for everyone Sure, that would work... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Moving nova.rpc into openstack.common
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. While we're at it, is it time to drop nova.rpc.impl_carrot? It is marked as deprecated in Essex. Is there any reason anyone would still use impl_carrot over impl_kombu? Thoughts? Thanks, -- 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
Re: [Openstack] Moving nova.rpc into openstack.common
I started looking into moving the notification drivers as well, but punted because of the reliance on multiple things, RPC included. For us, it's a nice to have but not a need. As for your plan, it seems sensible to me. On 4/2/12 3:26 PM, Russell Bryant rbry...@redhat.com 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. While we're at it, is it time to drop nova.rpc.impl_carrot? It is marked as deprecated in Essex. Is there any reason anyone would still use impl_carrot over impl_kombu? Thoughts? Thanks, -- 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
+1 Thanks for exploring this, Russell! Next step: getting a common REST API abstraction in place that all the projects can use... ;-) d On Mon, Apr 2, 2012 at 4:26 PM, Russell Bryant rbry...@redhat.com 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. While we're at it, is it time to drop nova.rpc.impl_carrot? It is marked as deprecated in Essex. Is there any reason anyone would still use impl_carrot over impl_kombu? Thoughts? Thanks, -- 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving nova.rpc into openstack.common
Seems like a sensible plan. Carrot can go now. I marked it deprecated so we can remove in folsom. I can take care of this today, even. On Apr 2, 2012, at 3:02 PM, Duncan McGreggor dun...@dreamhost.com wrote: +1 Thanks for exploring this, Russell! Next step: getting a common REST API abstraction in place that all the projects can use... ;-) d On Mon, Apr 2, 2012 at 4:26 PM, Russell Bryant rbry...@redhat.com 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. While we're at it, is it time to drop nova.rpc.impl_carrot? It is marked as deprecated in Essex. Is there any reason anyone would still use impl_carrot over impl_kombu? Thoughts? Thanks, -- 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
