[openstack-dev] [cross-project] [all] Quotas -- service vs. library

Sean Dague sean at dague.net
Wed Mar 16 12:42:45 UTC 2016


On 03/16/2016 08:27 AM, Amrith Kumar wrote:
> Nikhil, thank you for the very timely posting. This is a topic that has
> been discussed quite a bit recently within the Trove team. I've read the
> document you reference as [1] and I have not been part of earlier
> conversations on this subject so I may be missing some context here.
> 
> I feel that the conversation (in [1], in the email thread) has gone to a
> discussion of implementation details (library vs. service, quota
> enforcement engine, interface, ...) when I think there is still some
> ambiguity in my mind about the requirements. What is it that this
> capability will provide and what is the contract implied when a service
> adopts this model.
> 
> For example, consider this case that we see in Trove. In response to a
> user request to create a cluster of databases, Trove must provision
> storage (cinder), compute (nova), networks (let's say neutron), and so
> on. As stated by Boris in his email, it would be ideal if Trove had a
> confirmation from all projects that there was quota available for the
> requests that would be made before the requests actually are made. This
> implies therefore that participating projects (cinder, nova, neutron,
> ...) would have to support some reservations scheme and subsequently
> honor requests based on a reservation. So, I think there's more to this
> than just another library or project, there's an implication for
> projects that wish to participate in this scheme. Or am I wrong in this
> understanding?

I think you have to wind it back further. While Trove wants to get a
consistent lock on quotas in all the projects below it, any single one
of those is massively racy on it's internal quota.

It's totally possible to have nova believe it has enough cpu, memory,
disk, security_groups, floating_ips, instances available for your user,
fail on a reschedule, and end up leaking off chunks of this, and
eventually fail you. So before asking the question about "Can Trove get
a unified quota answer" we have to solve "can the underlying projects
guaruntee consistent quota answers".

There is a giant pile of bugs in Nova about these races, has been
forever, until we solve this in the lower level projects there is no
hope of solving the Trove use case.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list