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: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
