[openstack-dev] [Oslo] Layering olso.messaging usage of config
markmc at redhat.com
Fri Dec 6 13:19:54 UTC 2013
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
> I don't think I missed too much, though I didn't run into all tiny
> 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
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:
(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:
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
More information about the OpenStack-dev