This will prevent them being registered on the global config object
and becoming available to consuming applications.
Change-Id: Ibddb876d18c6aefef9dca08cf5883d8bdca17925
bp graduate-oslo-concurrency
This is more lib-ish than calling python -m on the module.
As part of this change, I also improved the unit tests for this code.
Before we weren't unsetting OSLO_LOCK_PATH before calling the main
function, so we had no way of knowing if it was being set correctly.
I also added a test case to verify return value propagation and
removed a private method that was never called.
Change-Id: I6c35b5409bf567767c5c71b9041dd7f7a012255d
* Adds an opts module for the config generator to use.
* Makes the opts in lockutils private since we don't want consumers
using them directly.
* Moves the options to an oslo_concurrency group with appropriate
deprecated_group settings to keep existing configs working.
Change-Id: Ifdb4d99e27588e8a91d941c60b248ea526c06e0a
commit b0d0c335 added remove external lock file function, but
the lock_path as lock file location folder is missing and
it make it's impossible to specify where to find the lock file.
This patch added the params.
Change-Id: I9be2fb68fab4690993395d01ef5ad13c0c92f3a3
Related-Bug: #1256306
* Cleanup lockutils logging by showing lock name and function in
same line. The enables easier parsing of information related to lock
acquisition from logs.
* Logs time a thread spent waiting on locks, as well as time spent
holding locks. This will make it easier to debug suboptimal locking.
Change-Id: Ic310d84eb1ed75cc1c21c3d7861b4a3927ebaf23
To be better able to identify when and where are file lock
breaks when release occurs it's useful to distingush the
different steps of release and independently log them as
unique steps.
Change-Id: I3b605994ca7673e5c97e73821d2ea777117f5f09
The old logging statements in lockutils made for some confusing log
entries where it would appear a given lock was acquired multiple
times by different threads at the same time. See referenced bug
for details.
In order to alleviate that confusion, this change does a few things:
1) Adds an explicit "acquired" message inside the lock so it is
clear when the lock was actually acquired.
2) Moves the release message inside the semaphore so there's no
chance of it being logged out of order.
3) Removes the "Got semaphore" message and splits it into two
separate messages depending on whether the semaphore was found
in the weakref dictionary. Making it clear which code path
was followed should help with future debugging.
Change-Id: I0fbb473c60d48c9704597d9e3634402857861a66
Closes-Bug: 1367941
Adds a note to the lock_path help text explaining how to secure the
target directory. Also opens lock files in append mode so there is
no possibility of overwriting a file due to a malicious symlink.
Change-Id: I77b72b20088fe66b573c23bd1fd98376c2b0f168
After a lot of discussion[1], it was decided that this is the
safest way forward. In the future we can investigate alternative
locking methods, probably as opt-ins so we don't break any
existing consumers of these locks.
[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/043090.html
Change-Id: I49ff98abc395d3263d55aeff26081b462a8a294e
Partial-Bug: 1327946
