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