Open Stack

On Fri, 2013-12-06 at 15:41 +0100, Julien Danjou wrote:
> On Fri, Dec 06 2013, Mark McLoughlin wrote:
> 
> Hi Mark,
> 
> > If the goal is "allow applications to use oslo.messaging without using
> > oslo.config", then what's driving this? I'm guessing some possible
> > answers:
> >
> >   5) But I want to avoid any dependency on oslo.config
> 
> I think that's the more important one to me.
> 
> >      This could be fundamentally what we're talking about here, but I 
> >      struggle to understand it - oslo.config is pretty tiny and it only 
> >      requires argparse, so if it's just an implementation detail that 
> >      you don't even notice if you're not using config files then what 
> >      exactly is the problem?
> 
> > Basically, my thinking is that something like this example:
> >
> >   https://gist.github.com/markmc/7823420
> >
> > where you can use oslo.messaging with just a dict of config values
> > (rather than having to parse config files) should handle any reasonable
> > concern that I've understood so far ... without having to change much at
> > all.
> 
> I definitely agree with your arguments. There's a large number of
> technical solutions that can be used to bypass the usage of oslo.config
> and make it work with whatever you're using..
> 
> I just can't stop thinking that a library shouldn't impose any use of a
> configuration library. I can pick any library on PyPI, and, fortunately,
> most of them don't come with a dependency on the favorite configuration
> library of their author or related project, and its usage spread all
> over the code base.
> 
> While I do respect the fact that this is a library to be consumed mainly
> in OpenStack (and I don't want to break that), I think we're also trying
> to not be the new Zope and contribute in a sane way to the Python
> ecosystem. And I think oslo.messaging doesn't do that right.
> 
> Now if the consensus is to leave it that way, I honestly won't fight it
> over and over. As Mark proved, there's a lot of way to circumvent the
> oslo.config usage anyway.

Ok, let's say oslo.messaging didn't use oslo.config at all and just took
a free-form dict of configuration values. Then you'd have this
separation whereby you can write code to retrieve those values from any
number of possible configuration sources and pass them down to
oslo.messaging. I think that's what you're getting at?

However, what you lose with that is a consistent way of defining a
schema for those configuration options in oslo.messaging. Should a given
option be an int, bool or a list? What should it's default be? etc. etc.
That stuff would live in the integration layer that maps from
oslo.config to a dict, even though it's totally useful when you just
supply a dict.

I guess there's two sides to oslo.config - the option schemas and the
code to retrieve values from various sources (command line, config files
or overrides/defaults). I think the option schemas is a useful
implementation detail in oslo.messaging, even if the values don't come
from the usual oslo.config sources.

Mark.