Open Stack

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.