Dear All,
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
https://wiki.openstack.org/wiki/WholeHostAllocation 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
https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api.
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
https://wiki.openstack.org/wiki/Resource-reservation-service. 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.
In the review below, I am referring to the Mirantis proposal at
https://docs.google.com/document/d/1vsN9LLq9pEP4c5BJyfG8g2TecoPxWqIY4WMT1juNBPI/edit?pli=1
Here are four general comments/questions.
1. 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?
2. 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.
3. 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.
4. 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.
I think it's probably enough as a starting point. I propose we iterate
on this first and see where this is taking us.
Best regards,
Patrick
--
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
