Open Stack

>It is believed that reservation help to to reserve a set of resources
>beforehand and hence eventually preventing any other upcoming request
>(serial or parallel) to exceed quota if because of original request the
>project might have reached the quota limits.
>
>Questions :-
>1. Does reservation in its current state as used by Nova, Cinder, Neutron
>help to solve the above problem ?

In Cinder the reservations are useful for grouping quota
for a single request, and if the request ends up failing
the reservation gets rolled back. The reservations also
rollback automatically if not committed within a certain
time. We also use reservations with Cinder nested quotas
to group a usage request that may propagate up to a parent
project in order to manage commit/rollback of the request
as a single unit.

>
>2. Is it consistent, reliable ?  Even with reservation can we run into
>in-consistent behaviour ?

Others can probably answer this better, but I have not
seen the reservations be a major issue. In general with
quotas we're not doing the check and set atomically which
can get us in an inconsistent state with quota-update,
but that's unrelated to the reservations.

>
>3. Do we really need it ?
>

Seems like we need *some* way of keeping track of usage
reserved during a particular request and a way to easily
roll that back at a later time. I'm open to alternatives
to reservations, just wondering what the big downside of
the current reservation system is.

- Ryan McNair (mc_nair)