> It seems to me that having this separation of concerns in oslo.messaging > would be good idea. My plan is to move out the configuration object out > of the basic object, like I did in the first patch. > > I don't plan to break the configuration handling or so, I just think it > should be handled in a separate, individually testable part of the code. > > Ultimately, this would allow oslo.messaging to not be 'oslo' only, and > just being friendly with oslo.config and therefore OpenStack. A goal I > wish we'd had in more oslo library. :)
I'd like to see more decoupling here with oslo.config in a similar way that eventlet may be used, but is no longer necessary, when using oslo.messaging. That is to say, I agree with your premise, even if the patch and blueprint need work. I agree with Mark that a clear blueprint and plan should be outlined. I'm not happy with the blueprint as written, it is sparse, outlining your intention, rather than a plan of attack. I'd really like to know what the plan of attack here is, how this will affect the oslo.messaging API, what it will look like once complete. It shouldn't break the public API and if for some reason you don't think it is possible to keep that contract, it should be discussed. Personally, I'd be happy with a wiki page outlining these changes, linked to from the blueprint. Also, I've noticed that your blueprint is registered underneath Ceilometer. Once you move or recreate the blueprint, please email the list with the updated URL. -- Regards, Eric Windisch _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
