<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear All,<br>
<br>
There has been some discussions recently about project Climate on
Stackforge which aim is to provide host reservation services. This
project is somehow related to
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/WholeHostAllocation">https://wiki.openstack.org/wiki/WholeHostAllocation</a> in that Climate
intends to deal with the reservation part of dedicated resource
pools called Pclouds in that blueprint. Climate wiki page can be
found here
<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>.<br>
<br>
The purpose of that email is that a team at Mirantis is proposing to
extend the scope of that service so that all sorts of resources
(physical and virtual) could be reserved. The architectural approach
of Mirantis is giving a first shot of this extension at
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Resource-reservation-service">https://wiki.openstack.org/wiki/Resource-reservation-service</a>. We
reviewed the proposal to evaluate how it fits with the initial use
cases and objectives of Climate. However, as the scope is becoming
much bigger, I thought we'd better bring the discussion to the open
instead of discussing it in private so that everybody who a stake or
general interest in that subject can chime in.<br>
<br>
In the review below, I am referring to the Mirantis proposal at
<a class="moz-txt-link-freetext" href="https://docs.google.com/document/d/1vsN9LLq9pEP4c5BJyfG8g2TecoPxWqIY4WMT1juNBPI/edit?pli=1">https://docs.google.com/document/d/1vsN9LLq9pEP4c5BJyfG8g2TecoPxWqIY4WMT1juNBPI/edit?pli=1</a><br>
<br>
Here are four general comments/questions.<br>
<ol>
<li>The primary assumption of Climate is that the role of the
reservation service is to manage resource reservations and only
resource reservations. This is because reserving a resource
doesn't imply necessarily that the user wants to use it. In
fact, as a user I may decide not to use a reservation at all and
decide instead to resell it through some market place if that's
possible. In its proposal, Mirantis specifies that the
reservation service is also responsible for managing the life
cycle of the reservations like starting instances when a lease
becomes active. I foresee several situations where this behavior
is not desirable like reserved instances to be launched upon
some external conditions that can be time based or load based
regardless of the lease terms. In this situation, this is
typically not the reservation service but the auto-scaling
service (Heat) who's in charge. So, is it planned in your design
to make the life-cycle management part of the service optional
or completely disabled if not needed?<br>
<br>
</li>
<li>The proposal specifies that the usage workflow is to first
create a lease (with parameters including start and end dates)
and then populate it with resource reservations requests to the
Nova, Cinder, Neutron, ... APIs . I think this workflow can
create two kinds of problems. First, a lease request could be
synchronous or asynchronous but it should be transactional in my
opinion. A second problem is that it probably won't work for
physical host reservations since there is no support for that in
Nova API. Originally, the idea of Climate is that the lease
creation request contains the terms of the lease along with a
specification of the type of resource (e.g. host capacity) to be
reserved and the number of those. In the case of an immediate
lease, the request would return success if the lease can be
satisfied or failure otherwise. If successful, reservation is
effective as soon as the lease creation request returns. This I
think is a central principal both from a usability standpoint
and an operational standpoint. What a user wants to know is
whether a reservation can be granted in a all-or-nothing manner
at the time he is asking the lease. Second, an operator wants to
know what a lease entails operationally speaking both in terms
of capacity availability and planing at the time a user requests
the lease. Consequently, I think that the reservation API should
allow a user to specify in the lease request the number and type
of resource he wants to reserve along with the lease term
parameters and that the system responds yes or no in a
transactional manner.<br>
<br>
</li>
<li>The proposal specifies that a lease can contain a combo of
different resources types reservations (instances, volumes,
hosts, Heat stacks, ...) that can even be nested and that the
reservation service will somehow orchestrate their deployment
when the lease kicks in. In my opinion, many use cases (at least
ours) do not warrant for that level of complexity and so, if
that's something that is need to support your use cases, then it
should be delivered as module that can be loaded optionally in
the system. Our preferred approach is to use Heat for deployment
orchestration.<br>
<br>
</li>
<li>The proposal specifies that the Reservation Scheduler notifies
the Reservation Manager when a lease starts and ends. Do you
intend to send those notifications directly or through
Ceilometer? Reservation state changes are of general interest
for operational and billing purposes. I also think that the
Reservation Manager may want to query the Reservation Scheduler
to check the state of the ongoing leases and scheduled leased as
opposed to just being notified when a lease starts and ends.
That's because typically in the case of physical host
reservation, the Reservation Manager must anticipate (account
for) the time it takes to bootstrap and provision the hosts
before the lease starts.</li>
</ol>
<p>I think it's probably enough as a starting point. I propose we
iterate on this first and see where this is taking us.<br>
Best regards,<br>
Patrick<br>
</p>
<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>