(I unfortunately need to quote a second time since Chris cut half of the
message below)
Le 03/06/2015 03:48, Jay Pipes a écrit :
On 06/02/2015 07:25 PM, Chris Friesen wrote:
On 06/02/2015 02:36 PM, Andrew Laski wrote:
There used to be a project that I think was looking for an API like
this to
provide a reservation system, Climate or Blazar or something. There
was brief
talk of providing something like it for that use case, but the idea
was put on
the backburner to wait for the scheduling rework that's occurring.
The question in my mind is should the claim requests be in the Nova
API or come
from a scheduler API. And I tend to think that they should come from a
scheduler API.
Who owns the resources, nova or the scheduler?
In many cases only nova-compute can resolve races (resource tracking of
specific CPU cores, specific PCI devices, etc. in the face of parallel
scheduling) so unless we're going to guarantee no races then I think
claim requests should be a nova API call, and it should go all the way
down to nova-compute to make sure that the resources are actually
claimed.
That's actually how the system works today. And, IMHO, it's
inefficient. The nova-compute node should be the final arbiter of
whether a request for resources can be properly fulfilled by the
hypervisor, however, the scheduler should be the thing that "owns"
resource usage records for the partition of resource providers that
the scheduler process is responsible for.
I think the claim IDs should be returned from the scheduler API
instead of created within the nova-compute manager.
IHMO, having claims done in the scheduler and claim IDs given to
computes is a technical answer to an overall problem : since the
scheduler doesn't commit a transaction when it does the resource usage
check (here consume_from_instance() ), we need to provide a consistent
ID for saying "here, this was the ID of the transaction done when
consuming the resource usage of the request done by the scheduler".
That's actually pretty close to what we discussed during the scaling-out
scheduler session in Vancouver where notes are here :
https://etherpad.openstack.org/p/YVR-nova-scalling-out-scheduler-for-cells
The idea is that we would like to see a single atomic commit when doing
the reservation (the decrement of resource usage) so that distributed
schedulers could compete for concurrency by being optimistic and retry
if that's not possible (if the commit fails). That's what Google tried
to do with Omega, and MHO is that is a good direction. Now we have an
action to draft some proposal based on our talks, we have to follow-up
on that.
-Sylvain
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
