Hi Julien, On Mon, 2013-12-02 at 16:45 +0100, Julien Danjou wrote: > On Mon, Nov 18 2013, Julien Danjou wrote: > > > https://blueprints.launchpad.net/oslo/+spec/messaging-decouple-cfg > > So I've gone through the code and started to write a plan on how I'd do > things: > > https://wiki.openstack.org/wiki/Oslo/blueprints/messaging-decouple-cfg > > I don't think I missed too much, though I didn't run into all tiny > details. > > Please feel free to tell me if I miss anything obvious, otherwise I'll > try to start submitting patches, one at a time, to get this into shape > step by step.
Thanks for writing this up, I really appreciate it. I would like to spend more time getting to the bottom of what we're trying to solve here. 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: 1) I don't want to use a global CONF object This is a strawman - I think we all realize the conf object you pass to oslo.messaging doesn't have to be cfg.CONF. Just putting it here to make sure no-one's confused about that. 2) I don't want to have configuration files or command line options in order to use oslo.messaging But, even now, you don't actually have to parse the command line or any config files. See e.g. https://gist.github.com/markmc/7823230 3) Ok, but I want to be able to specify values for things like rpc_conn_pool_size without using any config files. We've talked about allowing the use of query parameters for stuff like this, but I don't love that. I think I'd restrict query parameters to those options which are fundamental to how you connect to a given transport. We could quite easily provide any API which would allow constructing a ConfigOpts object with a bunch of options set and without anyone having to use config files. Here's a PoC of how that might look: https://gist.github.com/markmc/7823420 (Now, if your reaction is "OMG, you're using temporary config files on disk, that's awful" then just bear with me an ignore the implementation details of get_config_from_dict(). We could very easily make oslo.config support a mode like this without needing to ever write anything to disk) The point of this example is that we could add an oslo.messaging API which takes a dict of config values and you never even know that oslo.config is involved. 4) But I want the API to be explicit about what config options are supported by the API This could be something useful to discuss, because right now the API hides configuration options rather than encoding them into the API. This is to give us a bit more flexibility about changing these over time (e.g. keeping backwards compat for old options for a short time than other aspects of the API). But actually, I'm assuming this isn't what you're thinking since your patch adds an free-form executor_kwargs dict. 5) But I want to avoid any dependency on oslo.config 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. Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev