[openstack-dev] Scheduler proposal
Neil.Jerram at metaswitch.com
Fri Oct 9 22:26:22 UTC 2015
FWIW - and somewhat ironically given what you said just before - I couldn't parse your last sentence below... You might like to follow up with a corrected version.
(On the broad point, BTW, I really agree with you. So much OpenStack discussion is rendered difficult to get into by use of wrong or imprecise language.)
From: Clint Byrum
Sent: Friday, 9 October 2015 19:08
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Scheduler proposal
Excerpts from Chris Friesen's message of 2015-10-09 10:54:36 -0700:
> On 10/09/2015 11:09 AM, Zane Bitter wrote:
> > The optimal way to do this would be a weighted random selection, where the
> > probability of any given host being selected is proportional to its weighting.
> > (Obviously this is limited by the accuracy of the weighting function in
> > expressing your actual preferences - and it's at least conceivable that this
> > could vary with the number of schedulers running.)
> > In fact, the choice of the name 'weighting' would normally imply that it's done
> > this way; hearing that the 'weighting' is actually used as a 'score' with the
> > highest one always winning is quite surprising.
> If you've only got one scheduler, there's no need to get fancy, you just pick
> the "best" host based on your weighing function.
> It's only when you've got parallel schedulers that things get tricky.
Note that I think you mean _concurrent_ not _parallel_ schedulers.
Parallel schedulers would be trying to solve the same unit of work by
breaking it up into smaller components and doing them at the same time.
Concurrent means they're just doing different things at the same time.
I know this is nit-picky, but we use the wrong word _A LOT_ and the
problem space is actually vastly different, as parallelizable problems
have a whole set of optimizations and advantages that generic concurrent
problems (especially those involving mutating state!) have a whole set
of race conditions that must be managed.
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev