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