Open Stack

(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: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev