<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 5:18 PM, yunhong jiang <span dir="ltr"><<a href="mailto:yunhong.jiang@linux.intel.com" target="_blank">yunhong.jiang@linux.intel.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 2013-11-18 at 15:32 -0800, Joe Gordon wrote:<br>
><br>
><br>
><br>
> On Mon, Nov 18, 2013 at 4:08 PM, yunhong jiang<br>
> <<a href="mailto:yunhong.jiang@linux.intel.com">yunhong.jiang@linux.intel.com</a>> wrote:<br>
>         On Mon, 2013-11-18 at 14:09 -0800, Joe Gordon wrote:<br>
>         ><br>
>         > Phil Day discussed this at the summit and I have finally<br>
>         gotten around<br>
>         > to posting a POC of this.<br>
>         ><br>
>         > <a href="https://review.openstack.org/#/c/57053/" target="_blank">https://review.openstack.org/#/c/57053/</a><br>
><br>
><br>
>         Hi, Joe, why you think the DB is not exact state in your<br>
>         followed commit<br>
>         message? I think the DB is updated to date by resource<br>
>         tracker, am I<br>
>         right (the resource tracker get the underlying resource<br>
>         information<br>
>         periodically but I think that information is mostly static).<br>
>         And I think<br>
>         the scheduler retry mainly comes from the race condition of<br>
>         multiple<br>
>         scheduler instance.<br>
><br>
><br>
><br>
><br>
> You answered the question yourself, the compute nodes (indirectly)<br>
> update the DB periodically, so the further you are from the last<br>
> periodic update the less up to date the DB is.<br>
><br>
</div>But the compute node will also update the DB if any claim changes<br>
between the period, and also considering currently the resource tracker<br>
calculate the instance usage (like RAM, core etc) itself instead of<br>
depends on hyper-visor report, I think the DB information should be<br>
considered mostly up to date.<br>
<br></blockquote><div><br></div><div>Yes, *mostly* up to date I agree, we can just make that word 'mostly' configurable.  Thanks for helping clarify this point.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Of course, I'm not against the information cache.<br>
<br>
--jyh<br>
<div class="HOEnZb"><div class="h5">><br>
> Its there for both reasons.  But yes it was originally put there<br>
> because of the multi scheduler race condition.<br>
><br>
><br>
>         "We already have the concept that the DB isn't the exact state<br>
>         of the<br>
>         world, right now it's updated every 10 seconds. And we use the<br>
>         scheduler<br>
>         retry mechanism to handle cases where the scheduler was wrong.<br>
>         "<br>
><br>
><br>
>         _______________________________________________<br>
>         OpenStack-dev mailing list<br>
>         <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>         <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>