Open Stack

On Tue, Apr 5, 2016, at 09:57 AM, Ryan McNair wrote:
> >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.

Jay goes into it a little bit in his response to another quota thread
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090560.html
and I share his thoughts here.

With a reservation system you're introducing eventual consistency into
the system rather than being strict because reservations are not tied to
a concrete thing. You can't do a point in time check of whether the
reserved resources are going to eventually be used if something happens
like a service restart and a request is lost. You have to have no
activity for the duration of the expiration time to let things settle
before getting a real view of quota usages.

Instead if you tie quota usage to the resource records then you can
always get a view of what's actually in use.

One thing that should probably be clarified in all of these discussion
is what exactly is the quota on. I see two answers: the quota is against
the actual resource usage, or the quota is against the records tracking
usage. Since we currently track quotas with a reservation system I think
it's fair to say that we're not actually tracking against resource like
disk/RAM/CPU being in use. I would consider the resource to be in use as
soon as there's a db record for something like an instance or volume
which indicates that there will be consumption of those resources. What
that means in practice is that quotas can be committed right away and
there doesn't seem to be any need for a reservation system.



> 
> - Ryan McNair (mc_nair)
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev