Open Stack

On 06/12/13 15:05 +0000, Mark McLoughlin wrote:
>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.
>

I tend to agree with the fact that oslo.messaging shouldn't depend on
a specific config library nor 'impose' it to the library consumers.
However, I must admit you make good points here. That said, I still
lean towards not making oslo.config a requirement for oslo.messaging. 

I've thought about another example that may make the use of
`get_config_from_dict` a bit awkward. If users want to change the
configuration parameters at runtime, they'll have to change them in 2
different configuration objects - the one they're already using and
oslo.config's. Is there a way to actually ease a case like while
keeping oslo.config and using a solution like the one you proposed?

Also, something to consider is that using something like
`get_config_from_dict` would help delaying the decision as to whether
oslo.messaging should depend on oslo.config. This change is a big,
breaking change and if we don't take a final decision now, we've to
make sure users of the library will be able to upgrade without much
pain.

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131209/7edc9f7c/attachment.pgp>