ons)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] Quota management and enforcement across projects
I'm resurrecting this thread to provide an update on this effort.
I have been looking at Boson [1] as a base for starting developing a service
for managing
I'm resurrecting this thread to provide an update on this effort.
I have been looking at Boson [1] as a base for starting developing a
service for managing quotas and reservations [2].
Boson's model would satisfy most of the requirements for this service, and
implementing additional requirements,
On 11/17/2014 05:49 PM, Salvatore Orlando wrote:
Hi all,
I am resuming this thread following the session we had at the summit in
Paris (etherpad here [1])
While there was some sort of consensus regarding what this library
should do, and how it should do it, the session ended with some open
ques
ept.
Best Regards
Chaoyi Huang ( Joe Huang )
-Original Message-
From: Kevin L. Mitchell [mailto:kevin.mitch...@rackspace.com]
Sent: Thursday, November 20, 2014 7:40 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Quota management and enforcement across projects
On Th
Apparently, like everything Openstack-y we have a gathered a good crowd of
people with different opinions, more or less different, more or less strong.
My only strong opinion is that any ocean-boiling attempt should be
carefully avoided, and any proposed approach should add as little as
possible in
On Thu, 2014-11-20 at 10:16 +1100, Blair Bethwaite wrote:
> For actions initiated directly through core OpenStack service APIs
> (Nova, Cinder, Neutron, etc - anything using Keystone policy),
> shouldn't quota-enforcement be handled by Keystone? To me this is just
> a subset of authz, and OpenStack
On 20 November 2014 05:25, wrote:
> --
>
> Message: 24
> Date: Wed, 19 Nov 2014 10:57:17 -0500
> From: Doug Hellmann
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Subject: Re: [openstack-dev] Quota
On Nov 19, 2014, at 9:51 AM, Sylvain Bauza wrote:
>
> Le 19/11/2014 15:06, Doug Hellmann a écrit :
>> On Nov 19, 2014, at 8:33 AM, Sylvain Bauza wrote:
>>
>>> Le 18/11/2014 20:05, Doug Hellmann a écrit :
On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell
wrote:
> On Mon, 201
Le 19/11/2014 15:06, Doug Hellmann a écrit :
On Nov 19, 2014, at 8:33 AM, Sylvain Bauza wrote:
Le 18/11/2014 20:05, Doug Hellmann a écrit :
On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell
wrote:
On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:
I’ve spent a bit of time thinking abo
On Nov 19, 2014, at 8:33 AM, Sylvain Bauza wrote:
>
> Le 18/11/2014 20:05, Doug Hellmann a écrit :
>> On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell
>> wrote:
>>
>>> On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:
I’ve spent a bit of time thinking about the resource ownership is
All I can say at the moment is that Usage and Quota management is a crappy
thing to do in OpenStack. Every service has it's own way of doing it both
in clients and api's. +n+ for making a effort in standardizing this thing
in a way that could be alike across projects..
2014-11-19 14:33 GMT+01:00 S
Le 18/11/2014 20:05, Doug Hellmann a écrit :
On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell
wrote:
On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:
I’ve spent a bit of time thinking about the resource ownership issue.
The challenge there is we don’t currently have any libraries that
On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell
wrote:
> On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:
>> I’ve spent a bit of time thinking about the resource ownership issue.
>> The challenge there is we don’t currently have any libraries that
>> define tables in the schema of an appl
On 18 November 2014 01:18, Kevin L. Mitchell
wrote:
> On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:
> > I’ve spent a bit of time thinking about the resource ownership issue.
> > The challenge there is we don’t currently have any libraries that
> > define tables in the schema of an appli
On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:
> I’ve spent a bit of time thinking about the resource ownership issue.
> The challenge there is we don’t currently have any libraries that
> define tables in the schema of an application. I think that’s a good
> pattern to maintain, since it
On Nov 17, 2014, at 5:49 PM, Salvatore Orlando wrote:
> Hi all,
>
> I am resuming this thread following the session we had at the summit in Paris
> (etherpad here [1])
>
> While there was some sort of consensus regarding what this library should do,
> and how it should do it, the session end
Hi all,
I am resuming this thread following the session we had at the summit in
Paris (etherpad here [1])
While there was some sort of consensus regarding what this library should
do, and how it should do it, the session ended with some open questions
which we need to address before finalising th
We can make it support whatever we want! :-)
The existing code almost certainly predates domain support in keystone, so I
think this is a case of needing to catch up not a conscious decision to leave
it out.
Doug
On Oct 15, 2014, at 12:15 PM, Ajaya Agrawal wrote:
> Hi,
>
> Would the new lib
Hi,
Would the new library support quota on domain level also? As it stands in
oslo-incubator it only does quota enforcement on project level only. The
use case for this is quota enforcement across multiple projects. For e.g.
as a cloud provider, I would like my customer to create only #X volumes
a
Sigh. Because I typed the wrong command. Thanks for pointing that out.
I don’t see any instances of “quota” in openstack-common.conf files:
$ grep quota */openstack-common.conf
or in any projects under "openstack/“:
$ ls */*/openstack/common/quota.py
ls: cannot access */*/openstack/common/quota
But why "policy" is being discussed on "quota" thread?
On Wed, Oct 15, 2014 at 11:55 AM, Valeriy Ponomaryov <
vponomar...@mirantis.com> wrote:
> Manila project does use "policy" common code from incubator.
>
> Our "small" wrapper for it:
> https://github.com/openstack/manila/blob/8203c51081680a7a
Manila project does use "policy" common code from incubator.
Our "small" wrapper for it:
https://github.com/openstack/manila/blob/8203c51081680a7a9dba30ae02d7c43d6e18a124/manila/policy.py
On Wed, Oct 15, 2014 at 2:41 AM, Salvatore Orlando
wrote:
> Doug,
>
> I totally agree with your findings o
Doug,
I totally agree with your findings on the policy module.
Neutron already has some "customizations" there and we already have a few
contributors working on syncing it back with oslo-incubator during the Kilo
release cycle.
However, my query was about the quota module.
>From what I gather it
On Oct 14, 2014, at 12:31 PM, Salvatore Orlando wrote:
> Hi Doug,
>
> do you know if the existing quota oslo-incubator module has already some
> active consumers?
> In the meanwhile I've pushed a spec to neutron-specs for improving quota
> management there [1]
It looks like a lot of projects
Hi Doug,
do you know if the existing quota oslo-incubator module has already some
active consumers?
In the meanwhile I've pushed a spec to neutron-specs for improving quota
management there [1]
Now, I can either work on the oslo-incubator module and leverage it in
Neutron, or develop the quota mo
On Oct 8, 2014, at 7:03 AM, Davanum Srinivas wrote:
> Salvatore, Joe,
>
> We do have this at the moment:
>
> https://github.com/openstack/oslo-incubator/blob/master/openstack/common/quota.py
>
> — dims
If someone wants to drive creating a useful library during kilo, please
consider adding t
Salvatore, Joe,
We do have this at the moment:
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/quota.py
-- dims
On Wed, Oct 8, 2014 at 2:29 AM, Salvatore Orlando wrote:
>
> On 8 October 2014 04:13, Joe Gordon wrote:
>>
>>
>> On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fai
On 8 October 2014 04:13, Joe Gordon wrote:
>
> On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg <
> morgan.fainb...@gmail.com> wrote:
>
>> Keeping the enforcement local (same way policy works today) helps limit
>> the fragility, big +1 there.
>>
>> I also agree with Vish, we need a uniform way to
On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg
wrote:
> Keeping the enforcement local (same way policy works today) helps limit
> the fragility, big +1 there.
>
> I also agree with Vish, we need a uniform way to talk about quota
> enforcement similar to how we have a uniform policy language / e
Keeping the enforcement local (same way policy works today) helps limit the
fragility, big +1 there.
I also agree with Vish, we need a uniform way to talk about quota
enforcement similar to how we have a uniform policy language / enforcement
model (yes I know it's not perfect, but it's far closer
Thanks Vish,
this seems a very reasonable first step as well - and since most projects
would be enforcing quotas in the same way, the shared library would be the
logical next step.
After all this is quite the same thing we do with authZ.
Duncan is expressing valid concerns which in my opinion can
The proposal in the past was to keep quota enforcement local, but to
put the resource limits into keystone. This seems like an obvious first
step to me. Then a shared library for enforcing quotas with decent
performance should be next. The quota calls in nova are extremely
inefficient right now and
Taking quota out of the service / adding remote calls for quota
management is going to make things fragile - you've somehow got to
deal with the cases where your quota manager is slow, goes away,
hiccups, drops connections etc. You'll also need some way of
reconciling actual usage against quota usa
> I recall that in the past there have been several calls for unifying quota
> management.
> The blueprint [1] for instance, hints at the possibility of storing quotas in
> keystone.
As an end-user: +1
For me it totally makes sense to put the quotas and access together.
> On the other hand, the
34 matches
Mail list logo
