2d2da74593
Wait for the legacy stack to move to the IN_PROGRESS state before returning from the API call in the stack update, suspend, resume, check, and restore operations. For the stack delete operation, do the same provided that we can acquire the stack lock immediately, and thus don't need to wait for existing operations to be cancelled before we can change the state to IN_PROGRESS. In other cases there is still a race. Change-Id: Id94d009d69342f311a00ed3859f4ca8ac6b0af09 Story: #1669608 Task: 23175
13 lines
694 B
YAML
13 lines
694 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Previously, the suspend, resume, and check API calls for all stacks, and
|
|
the update, restore, and delete API calls for non-convergence stacks,
|
|
returned immediately after starting the stack operation. This meant that
|
|
for a client reading the state immediately when performing the same
|
|
operation twice in a row, it could have misinterpreted a previous state as
|
|
the latest unless careful reference were made to the updated_at timestamp.
|
|
Stacks are now guaranteed to have moved to the ``IN_PROGRESS`` state before
|
|
any of these APIs return (except in the case of deleting a non-convergence
|
|
stack where another operation was already in progress).
|