Open Stack

On 03/16/2016 08:42 AM, Sean Dague wrote:
> 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.

[amrith] So do I understand that the intent of this project and proposal
is to help address the issues of each individual project, and leave the
cross-project issue for later (or a different project)?

I think it would be beneficial to think of the "unified quota problem"
while designing a solution to the "underlying project problem". It may
even be worthwhile thinking through the design of the unified quota
problem in detail, and implementing the whole thing in phases starting
with the issue of each project. Happy to help with this, let me know how
to volunteer.

> 	-Sean
>

--
Amrith Kumar, CTO                   | amrith at tesora.com
Tesora, Inc                         | @amrithkumar
125 CambridgePark Drive, Suite 400  | http://www.tesora.com
Cambridge, MA. 02140                | GPG: 0x5e48849a9d21a29b 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160316/ef695913/attachment.pgp>