Open Stack

Hi Matt, Andrey,
                        CERN-BARC team was working on nested quota implementation in Nova some 3 years back.But at that time, it was decided to fix bugs in the existing quota driver rather than  adding more features. After that , the Cinder team implemented nested quota in Cinder and at the same time, there was a plan to implement a quota library called  Delimiter.
    https://launchpad.net/delimiter
                     Unfortunately things have not progressed much.Actually,the main hurdle is the delay in having a concrete decision in the approach that needs to be adopted.While it is accepted that, there should be a common entity for quota management of various services like Nova, Cinder, Neutron, it has not been finalized whether that common entity should be a library or  a separate service itself.Both approaches are having its own pros and cons. But the main point is that we need to take a concrete decision in the approach that needs to be adopted, to make the things move forward.So IMHO it would be nice to have a discussion on hierarchical quotas at the PTG.
                                                                                                               best regards, 
                                                                                                                sajeesh
________________________________________                                                                                   
From: Andrey Volkov [avolkov at mirantis.com]
Sent: 13 February 2017 15:33:54
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Hierarchical quotas at the PTG?

Hi Matt,

> But it's unclear to some (at least me) what those
> issues are.


I believe issues were resolved. I made a retrospective by working with
bugs and repository history what problems cinder encountered with quotas.

- First, hierarchical quotas were implemented in DbQuotaDriver but
  after some time were moved to separated driver. It's definitely
  worth to left choice for an operator to determine what quotas driver is
  better for their case.

- Second, in nested quotas implementation sum of subproject usages was
  saved in a parent node. I mean there is the special column (allocated)
  in quotas limits table contains calculated value. I believe that was
  done for the sake of performance. In implementation was proposed to
  nova there is the different approach which doesn't cache usages in DB,
  and performance testing for such approach was done.

- Third, an issue with getting project from keystone due policy. To get
  projects from keystone service user was used because ordinary user's
  rights may be not enough. Additional complexity was due subtle
  conditions for quotas management. The proposed approach in nova also
  uses service user but doesn't touch anything related to quotas
  management.

> Has anyone already planned on talking about hierarchical quotas at the
> PTG, like the architecture work group?

I would like to discuss following topics on PTG:

- Hierarchical quotas approach in nova.

- Storing quotas in keystone service and limits migration from nova.

- ?Quotas on flavor level.

It's my first PTG so I don't sure how it can be done, anyway,
I'll prepare some information to share with the community.

> Is there still a group working on that and can provide some guidance
> here?

There are a couple of developers in Mirantis interested in this theme,
as Boris mentioned some work was done.

Matt Riedemann writes:

> Operators want hierarchical quotas [1]. Nova doesn't have them yet and
> we've been hesitant to invest scarce developer resources in them since
> we've heard that the implementation for hierarchical quotas in Cinder
> has some issues. But it's unclear to some (at least me) what those
> issues are.
>
> Has anyone already planned on talking about hierarchical quotas at the
> PTG, like the architecture work group?
>
> I know there was a bunch of razzle dazzle before the Austin summit about
> quotas, but I have no idea what any of that led to. Is there still a
> group working on that and can provide some guidance here?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-operators/2017-January/012450.html

--
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.

__________________________________________________________________________
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