<font size=2 face="sans-serif">I looked at the blueprint (</font><a href="https://blueprints.launchpad.net/heat/+spec/stacks-reservation"><font size=2 face="sans-serif">https://blueprints.launchpad.net/heat/+spec/stacks-reservation</font></a><font size=2 face="sans-serif">)
and associated wiki page (</font><a href=https://wiki.openstack.org/wiki/Heat/Reservation><font size=2 face="sans-serif">https://wiki.openstack.org/wiki/Heat/Reservation</font></a><font size=2 face="sans-serif">),
and I have a few comments/questions.</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">Will Climate be an independent service,
or part of Nova, or what?</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">I see use cases for immediate future
reservations; do you have use cases for more distant reservations?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Mike</font>