<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 16, 2016 at 6:25 AM, Nikhil Komawar <span dir="ltr"><<a href="mailto:nik.komawar@gmail.com" target="_blank">nik.komawar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
tl;dr;<br>
I'm writing to request some feedback on whether the cross project Quotas<br>
work should move ahead as a service or a library or going to a far<br>
extent I'd ask should this even be in a common repository, would<br>
projects prefer to implement everything from scratch in-tree? Should we<br>
limit it to a guideline spec?<br>
<br>
But before I ask anymore, I want to specifically thank Doug Hellmann,<br>
Joshua Harlow, Davanum Srinivas, Sean Dague, Sean McGinnis and  Andrew<br>
Laski for the early feedback that has helped provide some good shape to<br>
the already discussions.<br>
<br>
Some more context on what the happenings:<br>
We've this in progress spec [1] up for providing context and platform<br>
for such discussions. I will rephrase it to say that we plan to<br>
introduce a new 'entity' in the Openstack realm that may be a library or<br>
a service. Both concepts have trade-offs and the WG wanted to get more<br>
ideas around such trade-offs from the larger community.<br>
<br></blockquote><div>Would you mind to expand this "we" here?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Service:<br>
This would entail creating a new project and will introduce managing<br>
tables for quotas for all the projects that will use this service. For<br>
example if Nova, Glance, and Cinder decide to use it, this 'entity' will<br>
be responsible for handling the enforcement, management and DB upgrades<br>
of the quotas logic for all resources for all three projects. This means<br>
less pain for projects during the implementation and maintenance phase,<br>
holistic view of the cloud and almost a guarantee of best practices<br>
followed (no clutter or guessing around what different projects are<br>
doing). However, it results into a big dependency; all projects rely on<br>
this one service for right enforcement, avoiding races (if do not<br>
incline on implementing some of that in-tree) and DB<br>
migrations/upgrades. It will be at the core of the cloud and prone to<br>
attack vectors, bugs and margin of error.<br>
<br></blockquote><div>I'd prefer not. As lots of concern raised already ref. latency, extra api etc.<br></div><div>Based on the unifying the user interface, common api might be desired<br></div><div>option, but it's own service, not so much.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Library:<br>
A library could be thought of in two different ways:<br>
1) Something that does not deal with backed DB models, provides a<br>
generic enforcement and management engine. To think ahead a little bit<br>
it may be a ABC or even a few standard implementation vectors that can<br>
be imported into a project space. The project will have it's own API for<br>
quotas and the drivers will enforce different types of logic; per se<br>
flat quota driver or hierarchical quota driver with custom/project<br>
specific logic in project tree. Project maintains it's own DB and<br>
upgrades thereof.<br></blockquote><div><br>Partially decent idea, just the fact annoys me that this is climbing the tree<br></div><div>arse ahead. The individual API's is perhaps the worst option with common<br></div><div>code for the quotas as each project has their own requirements where the<br></div><div>API might be generalized.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) A library that has models for DB tables that the project can import<br>
from. Thus the individual projects will have a handy outline of what the<br>
tables should look like, implicitly considering the right table values,<br>
arguments, etc. Project has it's own API and implements drivers in-tree<br>
by importing this semi-defined structure. Project maintains it's own<br>
upgrades but will be somewhat influenced by the common repo.<br>
<br></blockquote><div>This is really not benefitting anyone. Again each project has their own<br>requirements for quotas, while the user experience is the one thing we<br></div><div>should try to unify. I have really difficulties to see Zaqar, Nova and Glance<br></div><div>fitting into the single quota model, while the API interacting with those could<br></div><div>be similar.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Library would keep things simple for the common repository and sourcing<br>
of code can be done asynchronously as per project plans and priorities<br>
without having a strong dependency. On the other hand, there is a<br>
likelihood of re-implementing similar patterns in different projects<br>
with individual projects taking responsibility to keep things up to<br>
date. Attack vectors, bugs and margin of error are project responsibilities<br>
<br></blockquote><div>This is the problem I see with oslo approach currently. Originally intended for<br></div><div>place to collect the common code from projects turning to "enforcing" entity<br></div><div>of code some people thinks should be common and does not fit most.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Third option is to avoid all of this and simply give guidelines, best<br>
practices, right packages to each projects to implement quotas in-house.<br>
Somewhat undesirable at this point, I'd say. But we're all ears!<br></blockquote><div><br></div><div>This is probably the best solution without "best practices", again one model<br></div><div>does not suite all, but common concepts, specially on the interacting API<br></div><div>side is desired. _If_ proven that most of the projects would fit to the same<br></div><div>suite, common lib could be built out of the outcome.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thank you for reading and I anticipate more feedback.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/284454/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/284454/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
Thanks,<br>
Nikhil<br>
<br></font></span></blockquote><div><br></div><div>I'd really like to see a project implementing quotas well, interacted via API<br></div><div>agreed on the API Working Group (not too specific so it can be adopted for<br></div><div>majority of use cases) and proved taking the corner cases into account. Like<br></div><div>starting with fixing the Cinder quotas in the first place (not pointing fingers but <br>looking for proof of success) and showing that the initiative has basis of<br></div><div>accountability.<br><br></div><div>Best,<br></div><div>Erno<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
<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>
</font></span></blockquote></div><br></div></div>