Open Stack

Le 02/06/2015 22:36, Andrew Laski a écrit :
> On 06/02/15 at 11:28am, Alexis Lee wrote:
>> Andrew Laski said on Mon, Jun 01, 2015 at 09:26:33AM -0400:
>>> However what these parameters give users, versus orchestrating
>>> outside of Nova, is the ability to have the instances all scheduled
>>> as a single block.
>>
>> We should seek to provide this via persistent claims. IE add to the
>> API something like:
>>
>>    claim([ResourceRequest]): [ResourceClaim]
>>    boot(ResourceClaim, Image, ...): Instance
>>    free_claim([ResourceClaim]): None
>>    check_claim([ResourceRequest]): [Boolean]
>>
>> (this is not a polished proposal!)
>>
>> This allows you to claim() space for many instances, either in one API
>> call or across several, before beginning to boot instances. check_claim
>> is an obvious extension for probing availability.
>
> 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.

Yeah, Blazar (formerly named Climate) was originally written to be on 
top of Nova and only calling the latter REST API to fire VMs when Blazar 
was asking for. All the concepts of capacity management was kept in 
Blazar and wasn't planned to be ported in Nova.
To be clear, it was a POC that we began to wrote 2 years ago and I 
personally came to the result it was a dead-end : due to quotas and 
resource usage in the scheduler, the 'reservation' engine needs to be in 
Nova or you will suffer all the PITA with race conditions in Blazar.

Now, let's be clear, the project is defunct since no commits happened 
over the last year. I'm also keen to consider that once the Nova 
scheduler will be in a reasonable state (still need to figure out what I 
call "reasonable"), the story could be achieved within Nova. It just 
needs to fix how we claim resources, how the quotas are managed in Nova, 
how the RT is providing resources to the scheduler, and lots of other 
tiny greety problems that we know we have. Said planned for M ? Not at all.


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


For the moment, there is no scheduler API :-)  That said, I understand 
your wonders and I'm going in the same direction by saying that the 
single source of truth for claiming for a placement is the scheduler.

Of course, that doesn't mean that the compute node can't check if it can 
fulfill the placement, but since the choice is made by the scheduler, 
then it has to be committed by the scheduler.

-Sylvain



>
>
>>
>> Paul Murray tells me there was a blueprint for this some time ago, but
>> I can't find a spec for it. I'm interested in pushing this, I'll put up
>> a spec at some point unless someone beats me to it.
>>
>>
>> Alexis
>> -- 
>> Nova Engineer, HP Cloud.  AKA lealexis, lxsli.
>>
>> __________________________________________________________________________ 
>>
>> 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
>
> __________________________________________________________________________ 
>
> 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