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:
[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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
