Open Stack

Hello everyone,

tl;dr;
I'm writing to request some feedback on whether the cross project Quotas
work should move ahead as a service or a library or going to a far
extent I'd ask should this even be in a common repository, would
projects prefer to implement everything from scratch in-tree? Should we
limit it to a guideline spec?

But before I ask anymore, I want to specifically thank Doug Hellmann,
Joshua Harlow, Davanum Srinivas, Sean Dague, Sean McGinnis and  Andrew
Laski for the early feedback that has helped provide some good shape to
the already discussions.

Some more context on what the happenings:
We've this in progress spec [1] up for providing context and platform
for such discussions. I will rephrase it to say that we plan to
introduce a new 'entity' in the Openstack realm that may be a library or
a service. Both concepts have trade-offs and the WG wanted to get more
ideas around such trade-offs from the larger community.

Service:
This would entail creating a new project and will introduce managing
tables for quotas for all the projects that will use this service. For
example if Nova, Glance, and Cinder decide to use it, this 'entity' will
be responsible for handling the enforcement, management and DB upgrades
of the quotas logic for all resources for all three projects. This means
less pain for projects during the implementation and maintenance phase,
holistic view of the cloud and almost a guarantee of best practices
followed (no clutter or guessing around what different projects are
doing). However, it results into a big dependency; all projects rely on
this one service for right enforcement, avoiding races (if do not
incline on implementing some of that in-tree) and DB
migrations/upgrades. It will be at the core of the cloud and prone to
attack vectors, bugs and margin of error.

Library:
A library could be thought of in two different ways:
1) Something that does not deal with backed DB models, provides a
generic enforcement and management engine. To think ahead a little bit
it may be a ABC or even a few standard implementation vectors that can
be imported into a project space. The project will have it's own API for
quotas and the drivers will enforce different types of logic; per se
flat quota driver or hierarchical quota driver with custom/project
specific logic in project tree. Project maintains it's own DB and
upgrades thereof.
2) A library that has models for DB tables that the project can import
from. Thus the individual projects will have a handy outline of what the
tables should look like, implicitly considering the right table values,
arguments, etc. Project has it's own API and implements drivers in-tree
by importing this semi-defined structure. Project maintains it's own
upgrades but will be somewhat influenced by the common repo.

Library would keep things simple for the common repository and sourcing
of code can be done asynchronously as per project plans and priorities
without having a strong dependency. On the other hand, there is a
likelihood of re-implementing similar patterns in different projects
with individual projects taking responsibility to keep things up to
date. Attack vectors, bugs and margin of error are project responsibilities

Third option is to avoid all of this and simply give guidelines, best
practices, right packages to each projects to implement quotas in-house.
Somewhat undesirable at this point, I'd say. But we're all ears!

Thank you for reading and I anticipate more feedback.

[1] https://review.openstack.org/#/c/284454/

-- 

Thanks,
Nikhil