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