Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140123/c1f1538b/attachment.html>