<div dir="ltr">Hi all,<div>During the analysis of the following bug:</div><div><a href="https://bugs.launchpad.net/heat/+bug/1418878">https://bugs.launchpad.net/heat/+bug/1418878</a><br></div><div>i figured out that orchestration engine doesn't work properly in some cases.</div><div>The case is the following: </div><div>trying to delete the same stack with resources n times in series.</div><div>It might happen if the stack deleting takes much time and a user is sending</div><div>the second delete request again.</div><div>Orchestration engine behavior is the following:</div><div>1) When first stack-delete command comes to heat service</div><div>it acquires the stack lock and sends delete request for resources</div><div>to other clients.</div><div>Unfortunately, the command does not start to delete resources from heat db. </div><div>2) At that time second stack-delete command for the same stack</div><div>comes to heat engine. It steals the stack lock, waits 0.2 (hard-coded constant!) </div><div>sec to allow previous stack-delete command finish the operations (of course, </div><div>the first didn't manage to finish deleting on time). After that engine service starts </div><div>the deleting again:</div><div>     - Request resources from heat DB (They exist!)</div><div>     - Send requests for delete to other clients (They do not exist because of </div><div>        point 1).</div><div>Finally, we have stack in DELETE_FAILED state because the clients raise</div><div>exceptions during stack delete.</div><div>I have some proposals how to fix it:</div><div>p1) Make waiting time (0.2 sec) configurable. It allows to finish stack-delete ops</div><div>before the second command starts deleting. From my point of view, it is just </div><div>workaround because different stacks (and operations) took different time.</div><div>p2) Try to deny lock stealing if the current thread executes deleting. As an option,</div><div>we can wait for the other thread if stack is deleting but it seems that it is not possible</div><div>to analyze with the current solution.</div><div>p3) Just leave it as it is. IMO, the last solution.</div><div>Do you have any other proposals how to manage such kind of cases?</div><div>Perhaps there is exists more proper solution.</div><div><br></div><div>Thank You,</div><div>Kairat Kushaev</div><div><br></div><div><br></div></div>