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 stilllean 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
pgpsrzQvZWPVI.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
