Open Stack

Hi Jamie,

Indeed, it is more important to be able to set quotas on every
resource in the context of public clouds, than in the context of
private clouds. With public cloud, we cannot assume that the user will
not (deliberately or not) create millions of users if he can.

I agree that there are several ways to implement quotas (e.g. in a
dedicated service or on the backend). From my point of view, it makes
sense to have it implemented in Keystone, since it manages these
resources, as it is done with other services.

Also, I understand that this may not be the priority for Keystone
right now.

Florent	Flament


----- Original Message -----
From: "Jamie Lennox" <jamielennox at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Sent: Tuesday, January 28, 2014 1:59:41 AM
Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on users and projects per domain



----- Original Message -----
> From: "Florent Flament" <florent.flament-ext at cloudwatt.com>
> To: openstack-dev at lists.openstack.org
> Sent: Friday, 24 January, 2014 8:07:28 AM
> Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on users and projects per domain
> 
> I understand that not everyone may be interested in such feature.
> 
> On the other hand, some (maybe shallow) Openstack users may be
> interested in setting quotas on users or projects. Also, this feature
> wouldn't do any harm to the other users who wouldn't use it.
> 
> If some contributors are willing to spend some time in adding this
> feature to Openstack, is there any reason not to accept it ?

I have in general no problem with users/projects/domains/etc being quota-ed
for a business decision (and i don't work for a provider) but as part of a more
global initiative that all resource types in OpenStack can be quotaed and this
would be managed by some other service (This i think would be a difficult
service to write). 

I don't see the point in implementing this directly as a keystone feature.
As Dolph mentioned these are not resource heavy concepts that we have a practical 
need to limit. In most situations i imagine service providers who want this
have means to achieve it via the backend they use store to. 

Note that the idea of storing quota data in keystone has come up before
and has generally never gained much traction. 

Jamie

> On Thu, 2014-01-23 at 14:55 -0600, Dolph Mathews wrote:
> > 
> > On Thu, Jan 23, 2014 at 9:59 AM, Florent Flament
> > <florent.flament-ext at cloudwatt.com> wrote:
> >         Hi,
> >         
> >         
> >         Although it is true that projects and users don't consume a
> >         lot of resources, I think that there may be cases where
> >         setting quotas (possibly large) may be useful.
> >         
> >         
> >         
> >         For instance, a cloud provider may wish to prevent domain
> >         administrators to mistakingly create an infinite number of
> >         users and/or projects, by calling APIs in a bugging loop.
> >         
> > 
> > 
> > That sounds like it would be better solved by API rate limiting, not
> > quotas.
> >  
> >         
> >         
> >         
> >         Moreover, if quotas can be disabled, I don't see any reason
> >         not to allow cloud operators to set quotas on users and/or
> >         projects if they wishes to do so for whatever marketing reason
> >         (e.g. charging more to allow more users or projects).
> >         
> > 
> > 
> > That's the shallow business decision I was alluding to, which I don't
> > think we have any reason to support in-tree.
> >  
> >         
> >         
> >         
> >         Regards,
> >         
> >         Florent Flament
> >         
> >         
> >         
> >         
> >         
> >         ______________________________________________________________
> >         From: "Dolph Mathews" <dolph.mathews at gmail.com>
> >         To: "OpenStack Development Mailing List (not for usage
> >         questions)" <openstack-dev at lists.openstack.org>
> >         Sent: Thursday, January 23, 2014 3:09:51 PM
> >         Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on
> >         users and projects per domain
> >         
> >         
> >         
> >         ... why? It strikes me as a rather shallow business decision
> >         to limit the number of users or projects in a system, as
> >         neither are actually cost-consuming resources.
> >         
> >         
> >         On Thu, Jan 23, 2014 at 6:43 AM, Matthieu Huin
> >         <matthieu.huin at enovance.com> wrote:
> >                 Hello,
> >                 
> >                 I'd be interested in opinions and feedback on the
> >                 following blueprint:
> >                 https://blueprints.launchpad.net/keystone/+spec/tenants-users-quotas
> >                 
> >                 The idea is to add a mechanism preventing the creation
> >                 of users or projects once a quota per domain is met. I
> >                 believe this could be interesting for cloud providers
> >                 who delegate administrative rights under domains to
> >                 their customers.
> >                 
> >                 I'd like to hear the community's thoughts on this,
> >                 especially in terms of viability.
> >                 
> >                 Many thanks,
> >                 
> >                 Matthieu Huin
> >                 
> >                 mhu at enovance.com
> >                 http://www.enovance.com
> >                 eNovance SaS - 10 rue de la Victoire 75009 Paris -
> >                 France
> >                 
> >                 
> >                 _______________________________________________
> >                 OpenStack-dev mailing list
> >                 OpenStack-dev at lists.openstack.org
> >                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >         
> >         
> >         
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >         
> >         
> >         
> >         
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >         
> > 
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev