An idea related to this, what would need to be done to make the DB have the exact state that a compute node is going through (and therefore the scheduler would not make unreliable/racey decisions, even when there are multiple schedulers). It's not like we are dealing with a system which can not know the exact state (as long as the compute nodes are connected to the network, and a network partition does not occur).
So maybe if we think about ways to correctly reserve resources, and keep up to date information about reserved resources we could then eliminate the race and eliminate the retries entirely? From: Joe Gordon <joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, November 18, 2013 3:32 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Nova] Does Nova really need an SQL database? On Mon, Nov 18, 2013 at 4:08 PM, yunhong jiang <yunhong.ji...@linux.intel.com<mailto:yunhong.ji...@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. 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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
