Open Stack

On 02/25/2015 06:41 AM, Daniel P. Berrange wrote:
> On Wed, Feb 25, 2015 at 02:08:32PM +0000, Gary Kotton wrote:
>> I understand that this is a high or critical bug but I think that
>> we need to discuss more on it and try have a more robust model.
>
> What I'm not seeing from the bug description is just what part of
> the scheduler needs the ability to have total summed disk across
> every host in the cloud.

The scheduler does not need to know this information at all. One might 
say that a cloud administrator would want to know the total free disk 
space available in their cloud -- or at least get notified once the 
total free space falls below some threshold. IMO, there are better ways 
of accomplishing such a capacity-management task: use an NPRE/monitoring 
check that simply does a `df` or similar command every so often against 
the actual filesystem backend.

IMHO, this isn't something that needs to be fronted by a 
management/admin-only REST API that needs to iterate over a potentially 
huge number of compute nodes just to enable some pretty graphical 
front-end that shows some pie chart of available disk space.

> What is the actual bad functional behaviour that results from this
> bug that means it is a high priority issue to fix ?

The higher priority thing would be to remove the wonky os-hypervisors 
REST API extension and its related cruft. This API extension is fatally 
flawed in a number of ways, including assumptions about things such as 
underlying providers of disk/volume resources and misleading 
relationships between the servicegroup API and the compute nodes table.

Best,
-jay