One question from me:

Will there be later fixes to remove oslo.config dependency/usage from oslo.concurrency?

I still don't understand how oslo.concurrency can be used as a library with the configuration being set in a static manner via oslo.config (let's use the example of `lock_path` @ For example:

Library X inside application Z uses lockutils (via the nice oslo.concurrency library) and sets the configuration `lock_path` to its desired settings, then library Y (also a user of oslo.concurrency) inside same application Z sets the configuration for `lock_path` to its desired settings. Now both have some unknown set of configuration they have set and when library X (or Y) continues to use lockutils they will be using some mix of configuration (likely some mish mash of settings set by X and Y); perhaps to a `lock_path` that neither actually wants to be able to write to...

This doesn't seem like it will end well; and will just cause headaches during debug sessions, testing, integration and more...

The same question can be asked about the `set_defaults()` function, how is library Y or X expected to use this (are they?)??

I hope one of the later changes is to remove/fix this??



On 08/07/2014 01:58 PM, Yuriy Taraday wrote:
> Hello, oslo cores.
> > I've finished polishing up oslo.concurrency repo at [0] - please take a > look at it. I used my new version of [1] to generate it, so
> history looks a bit different from what you might be used to.
> > I've made as little changes as possible, so there're still some steps left
> that should be done after new repo is created:
> - fix PEP8 errors H405 and E126;
> - use strutils from oslo.utils;
> - remove eventlet dependency (along with random sleeps), but proper testing
> with eventlet should remain;
> - fix for bug [2] should be applied from [3] (although it needs some
> improvements);
> - oh, there's really no limit for this...
> > I'll finalize and publish relevant change request to openstack-infra/config
> soon.
> > Looking forward to any feedback! > > [0]
> [1]
> [2]
> [3]
> > > > _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at

OpenStack-dev mailing list

Reply via email to