Open Stack

On Mon, Nov 18, 2013 at 5:18 PM, yunhong jiang <
yunhong.jiang at linux.intel.com> wrote:

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


> Of course, I'm not against the information cache.
>
> --jyh
> >
> > Its there for both reasons.  But yes it was originally put there
> > because of the multi scheduler race condition.
> >
> >
> >         "We already have the concept that the DB isn't the exact state
> >         of the
> >         world, right now it's updated every 10 seconds. And we use the
> >         scheduler
> >         retry mechanism to handle cases where the scheduler was wrong.
> >         "
> >
> >
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/19d1c56c/attachment.html>