This was most likely meant as a max 2s delay here, not a max 2ms
delay.
Also includes a related change: when retries for metadata updates are
attempted, make sure we do not have a stale value of the atomic_key
(otherwise we'll just inevitably hit the ConcurrentTransaction issue).
Reviewed: https:/ /review. openstack. org/466008 /git.openstack. org/cgit/ openstack/ heat/commit/ ?id=c52fdbb7d68 bb0814843f3fec9 b2d966239bab40
Committed: https:/
Submitter: Jenkins
Branch: stable/newton
commit c52fdbb7d68bb08 14843f3fec9b2d9 66239bab40
Author: Zane Bitter <email address hidden>
Date: Thu May 26 13:40:53 2016 -0400
Corrected max secs for concurrent trans retries
This was most likely meant as a max 2s delay here, not a max 2ms
delay.
Also includes a related change: when retries for metadata updates are action issue).
attempted, make sure we do not have a stale value of the atomic_key
(otherwise we'll just inevitably hit the ConcurrentTrans
Conflicts: engine/ service_ software_ config. py objects/ resource. py
heat/
heat/
Co-Authored-By: Crag Wolfe <email address hidden> db1f4752859d2b2 a9506922911 9ae8c0e2311de26 01b66c66b6)
Partial-Bug: #1651768
Change-Id: Ie56e0e4ff93633
(cherry picked from commit e37d9fab8fe2e77