<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 12 April 2016 at 15:48, Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
On Tue, Apr 5, 2016, at 09:57 AM, Ryan McNair wrote:<br>
> >It is believed that reservation help to to reserve a set of resources<br>
> >beforehand and hence eventually preventing any other upcoming request<br>
> >(serial or parallel) to exceed quota if because of original request the<br>
> >project might have reached the quota limits.<br>
> ><br>
> >Questions :-<br>
> >1. Does reservation in its current state as used by Nova, Cinder, Neutron<br>
> >help to solve the above problem ?<br>
><br>
> In Cinder the reservations are useful for grouping quota<br>
> for a single request, and if the request ends up failing<br>
> the reservation gets rolled back. The reservations also<br>
> rollback automatically if not committed within a certain<br>
> time. We also use reservations with Cinder nested quotas<br>
> to group a usage request that may propagate up to a parent<br>
> project in order to manage commit/rollback of the request<br>
> as a single unit.<br></div></div></blockquote><div><br></div><div>Neutron recently introduced reservations. </div><div>Without reservations it was theoretically possible for a tenant to achieve n times the amount of resources granted by the quota, where n is the number of workers or distinct server instances.</div><div>More informations are available in [1] and [2]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
><br>
> ><br>
> >2. Is it consistent, reliable ?  Even with reservation can we run into<br>
> >in-consistent behaviour ?<br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">><br>
> Others can probably answer this better, but I have not<br>
> seen the reservations be a major issue. In general with<br>
> quotas we're not doing the check and set atomically which<br>
> can get us in an inconsistent state with quota-update,<br>
> but that's unrelated to the reservations.<br></div></div></blockquote><div><br></div><div>I do not have any news of bugs, nor do I have any know issue that might affect consistency of the reservation system.</div><div>One know weakness has to do with galera clusters - as the reservation system uses the update lock which is pointless in this case.</div><div>Neutron handles the resulting write-set certification failure retrying the operation, which is quite expensive.</div><div>There were already proposals in the nova space to implement a lock-free CAS algorithm for reservations, but since then I've lost track of developments in the area.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
><br>
> ><br>
> >3. Do we really need it ?<br>
> ><br>
><br>
> Seems like we need *some* way of keeping track of usage<br>
> reserved during a particular request and a way to easily<br>
> roll that back at a later time. I'm open to alternatives<br>
> to reservations, just wondering what the big downside of<br>
> the current reservation system is.<br></div></div></blockquote><div><br></div><div>Like most things either one proactively ensures a desired condition is met, or reacts when that condition is not met anymore.</div><div>This means that without reservation - eg: optimistic enforcement - corrective steps must be taken after committing the transaction</div><div>that sent the resource over quota. This is completely ok in my opinion. For instance if taking corrective steps has a cost of 5 and</div><div>creating/committing a reservation has a cost of 2, the reactive approach is convenient if less than 1 request over 3 sends a resource</div><div>over quota (note: I've made the numbers up, I just wanted to make a point that reacting rather than being proactive can be convenient).</div><div><br></div><div>However, for Neutron the reactive approach simply won't work because Neutron leaves a certain degree of freedom to plugins, and several plugins operate on the backend before committing the DB transaction (I know it's probably not ok, but if we give them freedom to do so then we cannot complain I guess). In that case the rollback will be very expensive and it cannot be a simple DB operation as it has to involve the backend as well.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
<br>
</div></div>Jay goes into it a little bit in his response to another quota thread<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2016-March/090560.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-March/090560.html</a><br>
and I share his thoughts here.<br>
<br>
With a reservation system you're introducing eventual consistency into<br>
the system rather than being strict because reservations are not tied to<br>
a concrete thing. You can't do a point in time check of whether the<br>
reserved resources are going to eventually be used if something happens<br>
like a service restart and a request is lost. You have to have no<br>
activity for the duration of the expiration time to let things settle<br>
before getting a real view of quota usages.<br></blockquote><div><br></div><div>That is true. This is a problem in Neutron that I would like to address too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Instead if you tie quota usage to the resource records then you can<br>
always get a view of what's actually in use.<br></blockquote><div><br></div><div>Yup, but a reservation and current usage are two different things, aren't they?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
One thing that should probably be clarified in all of these discussion<br>
is what exactly is the quota on. I see two answers: the quota is against<br>
the actual resource usage, or the quota is against the records tracking<br>
usage. Since we currently track quotas with a reservation system I think<br>
it's fair to say that we're not actually tracking against resource like<br>
disk/RAM/CPU being in use. I would consider the resource to be in use as<br>
soon as there's a db record for something like an instance or volume<br>
which indicates that there will be consumption of those resources. What<br>
that means in practice is that quotas can be committed right away and<br>
there doesn't seem to be any need for a reservation system.<br></blockquote><div><br></div><div>I think it's fair to say that we track quota against usage counters _and_ reservations.</div><div>In my experience with Neutron the performance penalty of doing a count query versus accessing a record with the usage counter is not that impressive, and as for not using reservation my comment is that it is definitely possible, but not necessarily feasible or convenient. </div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/neutron/+bug/1468934">https://bugs.launchpad.net/neutron/+bug/1468934</a></div><div>[2] <a href="http://docs.openstack.org/developer/neutron/devref/quota.html">http://docs.openstack.org/developer/neutron/devref/quota.html</a> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
<br>
<br>
><br>
> - Ryan McNair (mc_nair)<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>