Open Stack

On 16/03/2016 06:28, Nikhil Komawar 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?

<snip>

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

In my view:

Pros:

1. Improved UX
   - Currently it is difficult to have a common method of updating
     and viewing project quotas is difficult, and (last time I looked)
     impossible in Horizon.
2. Much easier to iterate on quotas - e.g. Nested Quotas

Cons:

1. Latency
2. Yet another thing in the critical path of API requests
3. Keeping compatibility across releases to allow for phased upgrades
    could be problematic
4. How does the big tent feed into this - is it plugin based (which
    increases the complexity of deploying additional OpenStack services)
    or does this service have all projects in tree?

I know that there is probably tons of problems with this idea, but
something occurred to me, could we have this as part of keystone?

When a user gets a token, as part of the token they get a quota
object. It does a few things:

1. Removes the need for another service
2. Allows services to use an already existing interface
3. Still has a central place for updates / querying

It also has a few downsides that I can think of off the top of my head:

1. Mainly - would Keystone even be willing to take this as part of
    their mission statement?
2. PKI tokens would have to be re-issued to get new quotas
3. PKI Tokens would have to be invalidated when decreasing tokens
4. The token size might explode for PKI
5. Extra load on Keystone


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

This would actually work quite well for us in Designate as the quotas
component is a plugin, we could switch to a openstack-common style
system quite easily.

It does not help in the UX side of things - but seems like it is the
quickest route to something being completed.

> 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

- Graham