There is a slight difference in functools.wraps on python3.x and
on python2.x in regards to the __wrapped__ attribute that the six
version makes transparent; so instead of using the functools one
just use the six one to gain the added compatability.
Change-Id: Iccf2aede08504469c148ee5f81f448cadfc08d5e
As discussed in [1], the logging in lockutils is not ideal, both
in terms of clarity and volume. This change removes some
redundant or just plain unnecessary log messages, while improving
the remaining ones to provide more detail to help debugging
contention issues. Specifically, it:
* Adds timing information to external lock messages, similar
to what was already added for internal locks.
* Removes a now-unnecessary 'attempting' message that was only
useful for determining the timing info now included in the log
message itself.
* Removes a "released and closed" log message that isn't really
interesting since it happens after the file was unlocked, and
only tells us that the file was closed normally, when we would
only care if that step failed for some reason (which will still
be logged).
* Removes the logging in internal_lock that was primarily added
to debug a phantom problem with eventlet semaphores.
* Adds a parameter to the lock() context that tells it whether
to log its debug messages. This allows synchronized to not
log duplicate messages when it acquires a lock.
Changes for more intelligent logging, such as only logging when
contention occurs as opposed always, are left as a future
enhancement.
[1]: http://lists.openstack.org/pipermail/openstack-dev/2014-September/047181.html
Partial-Bug: 1374075
Change-Id: I7bb36cdbb2e0f1643e1499054433894142cd2ee3
Improve help string to state default value and that it's mandatory.
Document set_defaults function.
DocImpact: Document that the value needs to evaluate to a valid path.
So, either environment variable is set or option is set.
Change-Id: I481d2f8107476ba166a18bc56d3b4c1be5ff726f
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
