Open Stack

On 03/16/2016 05: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.

+1 I think/thought the goal was more of to solve all the above bugs 
first by doing something/thinking a little different and figuring out 
how to make this quota service (or library) a reality (finally!!)

Then sure, of course, we can work on those other problems as well 
(obviously we should try to design a initial solution that should not 
make solving those kinds of problems impossible).

-josh

>
> 	-Sean
>