Open Stack

Thanks for your feedback Erno. I've answered your question inline.

On 3/17/16 2:21 AM, Erno Kuvaja wrote:
> On Wed, Mar 16, 2016 at 6:25 AM, Nikhil Komawar <nik.komawar at gmail.com
> <mailto: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?
>  

Quota WG (
http://eavesdrop.openstack.org/#Cross-project_Quotas_and_Nested_Quotas_Working_Group_Virtual_Standup
)

>
>     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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
> __________________________________________________________________________
> 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
>
>


-- 

Thanks,
Nikhil