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
[email protected]
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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
