<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 11, 2014 at 5:44 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One question from me:<br>
<br>
Will there be later fixes to remove oslo.config dependency/usage from oslo.concurrency?<br>
<br>
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` @ <a href="https://github.com/YorikSar/oslo.concurrency/blob/master/oslo/concurrency/lockutils.py#L41" target="_blank">https://github.com/YorikSar/<u></u>oslo.concurrency/blob/master/<u></u>oslo/concurrency/lockutils.py#<u></u>L41</a>). For example:<br>


<br>
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...<br>


<br>
This doesn't seem like it will end well; and will just cause headaches during debug sessions, testing, integration and more...<br>
<br>
The same question can be asked about the `set_defaults()` function, how is library Y or X expected to use this (are they?)??<br>
<br>
I hope one of the later changes is to remove/fix this??<br>
<br>
Thoughts?<br>
<br>
-Josh</blockquote></div><div><br></div><div style>I'd be happy to remove lock_path config variable altogether. It's basically never used. There are two basic branches in code wrt lock_path:</div><div style>- when you provide lock_path argument to lock (and derivative functions), file-based lock is used and CONF.lock_path is ignored; </div>

<div style>- when you don't provide lock_path in arguments, semaphore-based lock is used and CONF.lock_path is just a prefix for its name (before hashing).</div><div><br></div><div style>I wonder if users even set lock_path in their configs as it has almost no effect. So I'm all for removing it, but...</div>

<div style>From what I understand, every major change in lockutils drags along a lot of headache for everybody (and risk of bugs that would be discovered very late). So is such change really worth it? And if so, it will require very thorough research of lockutils usage patterns.</div>

<div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>