Open Stack

On 7 October 2015 at 22:17, Chris Friesen <chris.friesen at windriver.com>
wrote:

> On 10/07/2015 07:23 PM, Ian Wells wrote:
>
>>
>> The whole process is inherently racy (and this is inevitable, and
>> correct),
>>
>>
> Why is it inevitable?
>

It's inevitable because everything takes time, and some things are
unpredictable.

The amount of free RAM on a machine - as we do it today - is, literally,
what the kernel reports to be free.  That's known by the host,
unpredictable, occasionally reported to the scheduler (which takes time),
and if you stored it in a database (which takes time) and recovered it from
a database (which takes time) the number you got would not be guaranteed to
be current.

Other things - like CPUs - can theoretically be centrally tracked, but the
whole thing is distributed at the moment - compute nodes are the source of
truth, not the database - which makes some sense when you consider that a
compute node knows best what VMs are running and what VMs have died at any
given moment.  In truth, if the central service is in any way wrong (for
instance, processes outside of Openstack are using a lot of CPU, which you
can't predict, again) then it makes sense for the compute node to be the
final arbiter, so (occasional, infrequent) reschedules are probably
appropriate anyway.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151008/8cabae13/attachment.html>