46c836ee28
When a lock can't be acquired there is currently a hard coded delay (0.01) that is used before trying again, instead of having a hard coded delay we should allow this delay to be configured since having it set at a hard coded value can limit concurrency (if the delay is actually way to high) or cause to much contention (if the delay is actually way to low). This review adds on that logic and also uses the retrying library to perform the acquisition attempts (and associated failures when/if they occur); as well as shows logs after a given amount of time has elapsed with the logs being output at a given periodicity. Change-Id: Ideeefba1439ddd677c608d01becb4f6a0d4bc83d
15 lines
449 B
Plaintext
15 lines
449 B
Plaintext
# The order of packages is significant, because pip processes them in the order
|
|
# of appearance. Changing the order has an impact on the overall integration
|
|
# process, which may cause wedges in the gate later.
|
|
|
|
pbr>=0.6,!=0.7,<1.0
|
|
Babel>=1.3
|
|
iso8601>=0.1.9
|
|
fixtures>=0.3.14
|
|
oslo.config>=1.4.0 # Apache-2.0
|
|
oslo.i18n>=1.0.0 # Apache-2.0
|
|
oslo.utils>=1.0.0 # Apache-2.0
|
|
posix_ipc
|
|
six>=1.7.0
|
|
retrying>=1.2.2,!=1.3.0 # Apache-2.0
|