[openstack-dev] [Oslo] Layering olso.messaging usage of config

Joshua Harlow harlowja at yahoo-inc.com
Mon Nov 18 18:22:25 UTC 2013

I see it as important (and not theoretical).

I'd like to use oslo.messaging (and oslo.messaging.rpc) in taskflow (to
prototype how a distributed engine would work using it) and bringing in a
library which requires global configuration is almost a non-starter for
me. Although taskflow is targeted at being used in openstack it still is a
generic library and a library shouldn't bring in dependencies which are
only configurable in 1 manner (via a global config via oslo.cfg); to me
that¹s bad style & forces an ideology on users of taskflow (which limits

So maybe this is a use-case that can be the rationale for oslo.messaging?

On 11/18/13 8:46 AM, "Mark McLoughlin" <markmc at redhat.com> wrote:

>On Mon, 2013-11-18 at 17:37 +0100, Julien Danjou wrote:
>> On Mon, Nov 18 2013, Mark McLoughlin wrote:
>> > I'm struggling to care about this until I have some insight into why
>> > it's important. And it's a bit frustrating to have to guess the
>> > rationale for this. Like commit messages, blueprints should be as much
>> > about the why as the what.
>> Sure. I ought to think that having an application that wants to leverage
>> oslo.messaging but is not using oslo.config and is retrieving its
>> parameter from another way is a good enough argument.
>It's a theoretical benefit versus the very practical "design an API for
>the use cases that are actually important to OpenStack projects".
>> > As I said in the review, I'm totally fine with the idea of allowing
>> > oslo.messaging to be used without a configuration object ... but I
>> > the common use case is to use it with a configuration object and I
>> > want to undermine the usability of the library in the common use case.
>> Understood. I know it's already a pain to transition from RPC to
>> messaging, and I don't want to add more burden on that transition.
>Cool, thanks.
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list