Open Stack

I looked at the blueprint (
https://blueprints.launchpad.net/heat/+spec/stacks-reservation) and 
associated wiki page (https://wiki.openstack.org/wiki/Heat/Reservation), 
and I have a few comments/questions.

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?

Will Climate be an independent service, or part of Nova, or what?

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?

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?

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.

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?

I see use cases for immediate future reservations; do you have use cases 
for more distant reservations?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131006/4ec38e00/attachment.html>