<div dir="ltr"><div>Sorry for flood,<br></div><div>i forgot p4:</div><div>Prohibit stack deletion if the current stack state, status = (DELETE, IN PROGRESS).</div><div>Raise not supported exception in heat engine. It is possible because stack state </div><div>will be updated before deleting.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 10, 2015 at 2:04 PM, Kairat Kushaev <span dir="ltr"><<a href="mailto:kkushaev@mirantis.com" target="_blank">kkushaev@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div>During the analysis of the following bug:</div><div><a href="https://bugs.launchpad.net/heat/+bug/1418878" target="_blank">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>
</blockquote></div><br></div>