<div dir="ltr"><div>Nikhil,</div><div><br></div><div>Thank you for rising this question. </div><div><br></div><div>IMHO quotas should be moved into separated services (this is right micro services approach). </div><div><br></div><div>It will make a lot of things simpler: </div><div>1) this removes a lot of logic/code from projects </div><div>2) cross project atomic quotas reservation (will be possible)</div><div>   (e.g. if we would like to reserver all required quotas, before running heat stack)</div><div>3) it will have better UX (you can change projects quotas from one place and unified) </div><div>4) simpler migrations for the projects (we don't need to maintain db migrations for each project)</div><div>    just imagine change in quotas lib that requires db migrations, we will need to run amount of projects migrations. </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 11:25 PM, 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>
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>
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>
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>
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>
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>
<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>
<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>