Open Stack

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

On 10/6/13 8:36 AM, Mike Spreitzer wrote:
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
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
http://www.bull.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131007/943a17c4/attachment.html>