Open Stack

On Wed, Mar 16, 2016 at 6:25 AM, Nikhil Komawar <nik.komawar at gmail.com>
wrote:

> 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.
>
> Would you mind to expand this "we" here?


> 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.
>
> I'd prefer not. As lots of concern raised already ref. latency, extra api
etc.
Based on the unifying the user interface, common api might be desired
option, but it's own service, not so much.


> 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.
>

Partially decent idea, just the fact annoys me that this is climbing the
tree
arse ahead. The individual API's is perhaps the worst option with common
code for the quotas as each project has their own requirements where the
API might be generalized.

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.
>
> This is really not benefitting anyone. Again each project has their own
requirements for quotas, while the user experience is the one thing we
should try to unify. I have really difficulties to see Zaqar, Nova and
Glance
fitting into the single quota model, while the API interacting with those
could
be similar.

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
>
> This is the problem I see with oslo approach currently. Originally
intended for
place to collect the common code from projects turning to "enforcing" entity
of code some people thinks should be common and does not fit most.


> 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!
>

This is probably the best solution without "best practices", again one model
does not suite all, but common concepts, specially on the interacting API
side is desired. _If_ proven that most of the projects would fit to the same
suite, common lib could be built out of the outcome.

>
> Thank you for reading and I anticipate more feedback.
>
> [1] https://review.openstack.org/#/c/284454/
>
> --
>
> Thanks,
> Nikhil
>
>
I'd really like to see a project implementing quotas well, interacted via
API
agreed on the API Working Group (not too specific so it can be adopted for
majority of use cases) and proved taking the corner cases into account. Like
starting with fixing the Cinder quotas in the first place (not pointing
fingers but
looking for proof of success) and showing that the initiative has basis of
accountability.

Best,
Erno

>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160317/4925fba9/attachment.html>