<div dir="ltr">any comments on this?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 2:50 PM, 王华 <span dir="ltr"><<a href="mailto:wanghua.humble@gmail.com" target="_blank">wanghua.humble@gmail.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><br></div><div>In order to prevent race conditions due to multiple conductors, my solution is as blew:</div><div>1. remove the db operation in bay_update to prevent race conditions.Stack operation is atomic. Db operation is atomic. But the two operations together are not atomic.So the data in the db may be wrong.</div><div>2. sync up stack status and stack parameters(now only node_count) from heat by periodic tasks. bay_update can change stack parameters, so we need to sync up them.</div><div>3. remove heat poller, because we have periodic tasks.</div><div><br></div><div>To sync up stack parameters from heat, we need to show stacks using admin_context. But heat don't allow to show stacks in other tenant. If we want to show stacks in other tenant, we need to store auth context for every bay. That is a problem. Even if we store the auth context, there is a timeout for token. The best way I think is to let heat allow admin user to show stacks in other tenant. </div><div><br></div><div>Do you have a better solution or any improvement for my solution?</div><div><br></div><div>Regards,</div><div>Wanghua</div></div>
</blockquote></div><br></div>