Open Stack

Yes, that helps.  Please, guys, do not interpret my questions as 
hostility, I really am just trying to understand.  I think there is some 
overlap between your concerns and mine, and I hope we can work together.

Sticking to the physical reservations for the moment, let me ask for a 
little more explicit details.  In your outline below, late in the game you 
write "the actual reservation is performed by the lease manager plugin". 
Is that the point in time when something (the lease manager plugin, in 
fact) decides which hosts will be used to satisfy the reservation?  Or is 
that decided up-front when the reservation is made?  I do not understand 
how the lease manager plugin can make this decision on its own, isn't the 
nova scheduler also deciding how to use hosts?  Why isn't there a problem 
due to two independent allocators making allocations of the same resources 
(the system's hosts)?

Thanks,
Mike

Patrick Petit <patrick.petit at bull.net> wrote on 10/07/2013 07:02:36 AM:

> Hi Mike,
> 
> There are actually more facets to this. Sorry if it's a little 
> confusing :-( Climate's original blueprint https://
> wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api
> was about physical host reservation only. The typical use case 
> being: "I want to reserve x number of hosts that match the 
> capabilities expressed in the reservation request". The lease is 
> populated with reservations which at this point are only capacity 
> descriptors. The reservation becomes active only when the lease 
> starts at a specified time and for a specified duration. The lease 
> manager plugin in charge of the physical reservation has a planning 
> of reservations that allows Climate to grant a lease only if the 
> requested capacity is available at that time. Once the lease becomes
> active, the user can request instances to be created on the reserved
> hosts using a lease handle as a Nova's scheduler hint. That's 
> basically it. We do not assume or enforce how and by whom (Nova, 
> Heat ,...) a resource instantiation is performed. In other words, a 
> host reservation is like a whole host allocation https://
> wiki.openstack.org/wiki/WholeHostAllocation that is reserved ahead 
> of time by a tenant in anticipation of some workloads that is bound 
> to happen in the future. Note that while we are primarily targeting 
> hosts reservations the same service should be offered for storage. 
> Now, Mirantis brought in a slew of new use cases that are targeted 
> toward virtual resource reservation as explained earlier by Dina. 
> While architecturally both reservation schemes (physical vs virtual)
> leverage common components, it is important to understand that they 
> behave differently. For example, Climate exposes an API for the 
> physical resource reservation that the virtual resource reservation 
> doesn't. That's because virtual resources are supposed to be already
> reserved (through some yet to be created Nova, Heat, Cinder,... 
> extensions) when the lease is created. Things work differently for 
> the physical resource reservation in that the actual reservation is 
> performed by the lease manager plugin not before the lease is 
> created but when the lease becomes active (or some time before 
> depending on the provisioning lead time) and released when the lease 
ends.
> HTH clarifying things.
> BR,
> Patrick 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/d65c6ed0/attachment.html>