<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Mike,<br>
<br>
There are actually more facets to this. Sorry if it's a little
confusing :-( Climate's original blueprint
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api">https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api</a>
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
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/WholeHostAllocation">https://wiki.openstack.org/wiki/WholeHostAllocation</a> 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.<br>
HTH clarifying things.<br>
BR,<br>
Patrick <br>
<br>
On 10/6/13 8:36 AM, Mike Spreitzer wrote:<br>
</div>
<blockquote
cite="mid:OF93C4D91A.88F48FE7-ON85257BFC.00221606-85257BFC.00244772@us.ibm.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<font face="sans-serif" size="2">I looked at the blueprint (</font><a
moz-do-not-send="true"
href="https://blueprints.launchpad.net/heat/+spec/stacks-reservation"><font
face="sans-serif" size="2">https://blueprints.launchpad.net/heat/+spec/stacks-reservation</font></a><font
face="sans-serif" size="2">)
and associated wiki page (</font><a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Heat/Reservation"><font
face="sans-serif" size="2">https://wiki.openstack.org/wiki/Heat/Reservation</font></a><font
face="sans-serif" size="2">),
and I have a few comments/questions.</font>
<br>
<br>
<font face="sans-serif" size="2">The wiki page has some remarks
that
are Nova-centric, and some other remarks that emphasize that
Climate is
not just about Nova, and I do not understand the relationship
between these
remarks. Is this a roadmapping thought (start with just Nova,
expand
to other services later), or the inclusion of some details
(related to
Nova) and omission of other similar details (related to the
other services),
or what?</font>
<br>
<br>
<font face="sans-serif" size="2">Will Climate be an independent
service,
or part of Nova, or what?</font>
<br>
<br>
<font face="sans-serif" size="2">What will be the atomic
operations?
I presume the primary interesting operation will be something
like
reserving a bag of resources, where that bag is allowed to
contain any
mixture of resources from any services. Have I got that right?</font>
<br>
<br>
<font face="sans-serif" size="2">What exactly does reserving a
resource
mean? Does this atomic reservation operation include some
atomic
cooperation from the resources' services' schedulers (e.g., Nova
scheduler,
Cinder scheduler, etc)? Or is this reservation service
logically
independent of the resources' primary schedulers? Overall I am
getting
the suggestion that reservation is an independent service. The
flow
is something like first reserve a bag of resources, and then
proceed to
use them at your leisure. But I also suppose that the important
thing
about a reservation is that it includes the result of scheduling
(placement)
--- the point of a reservation is that it is holding capacity to
host the
reserved resources. You do not want an atomic operation to take
a
long time; do the scheduling decisions get made (tentatively, of
course)
before the real atomic section, with re-schedule and re-try on
conflict
detection, or is scheduling included in the atomic section?</font>
<br>
<br>
<font face="sans-serif" size="2">For how long does a reservation
last?
What sort of thing owns a reservation? I suppose one important
use case is that a heat engine, or the heat service (in the
multi-engine
world), could own a reservation; in this use case, the
reservation would
last until heat releases it. Hopefully heat will persist its
reservation
information, so that a process crash will not cause a dangling
reservation;
how will you enable complete avoidance of timing splinters
(e.g., heat
engine crashes after making reservation but before persisting
information
about it)? Presumably other things besides heat could own
reservations.</font>
<br>
<br>
<font face="sans-serif" size="2">Is this primarily about planning
for
the distant future, or focused on the immediate future? If a
bag
of resources (including their backing capacities) is reserved
for a period
that starts more than a little while in the future, what is done
with that
backing capacity in the meantime?</font>
<br>
<br>
<font face="sans-serif" size="2">I see use cases for immediate
future
reservations; do you have use cases for more distant
reservations?</font>
<br>
<br>
<font face="sans-serif" size="2">Thanks,</font>
<br>
<font face="sans-serif" size="2">Mike</font>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
<a class="moz-txt-link-freetext" href="http://www.bull.com">http://www.bull.com</a></pre>
</body>
</html>