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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to