Open Stack

On 08/11/2014 01:02 PM, Yuriy Taraday wrote:
> On Mon, Aug 11, 2014 at 5:44 AM, Joshua Harlow <harlowja at outlook.com> wrote:
> 
>> 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` @ https://github.com/YorikSar/
>> oslo.concurrency/blob/master/oslo/concurrency/lockutils.py#L41). 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??
>>
>> Thoughts?
>>
>> -Josh
> 
> 
> 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:
> - when you provide lock_path argument to lock (and derivative functions),
> file-based lock is used and CONF.lock_path is ignored;
> - 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).
> 
> 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...
> 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.

Two things lock_path has to stay for: Windows and consumers who require
file-based locking semantics.  Neither of those use cases are trivial to
remove, so IMHO it would not be appropriate to do it as part of the
graduation.  If we were going to alter the API that much it needed to
happen in incubator.

As far as lock_path mismatches, that shouldn't be a problem unless a
consumer is doing something very unwise.  Oslo libs get their
configuration from the application using them, so unless the application
passes two separate conf objects to library X and Y they're both going
to get consistent settings.  If someone _is_ doing that, then I think
it's their responsibility to make sure the options in both config files
are compatible with each other.

-Ben