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
__________________________________________________________________________
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
