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.) Regards, Neil Original Message From: Clint Byrum Sent: Friday, 9 October 2015 19:08 To: openstack-dev 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev