Open Stack

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

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