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