<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 9:59 AM, Florent Flament <span dir="ltr"><<a href="mailto:florent.flament-ext@cloudwatt.com" target="_blank">florent.flament-ext@cloudwatt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div>Hi,</div><div><br></div><div>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.<br>
</div><div><br></div><div>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.<br></div></div></div>
</blockquote><div><br></div><div>That sounds like it would be better solved by API rate limiting, not quotas.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div></div><div><br></div><div>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).<br>
</div></div></div></blockquote><div><br></div><div>That's the shallow business decision I was alluding to, which I don't think we have any reason to support in-tree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div></div><div><br></div><div>Regards,<br></div><div>Florent Flament</div><div><br></div><div><br></div><hr><div style="font-size:12pt;font-style:normal;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal">
<b>From: </b>"Dolph Mathews" <<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>><br><b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<b>Sent: </b>Thursday, January 23, 2014 3:09:51 PM<br><b>Subject: </b>Re: [openstack-dev] [Keystone] bp proposal: quotas on users and projects per domain<div><div class="h5"><br><div><br></div><div dir="ltr"><div class="gmail_extra">
... 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.<br><div><br></div><div class="gmail_quote">
On Thu, Jan 23, 2014 at 6:43 AM, Matthieu Huin <span dir="ltr"><<a href="mailto:matthieu.huin@enovance.com" target="_blank">matthieu.huin@enovance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I'd be interested in opinions and feedback on the following blueprint: <a href="https://blueprints.launchpad.net/keystone/+spec/tenants-users-quotas" target="_blank">https://blueprints.launchpad.net/keystone/+spec/tenants-users-quotas</a><br>
<br>
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.<br>
<br>
I'd like to hear the community's thoughts on this, especially in terms of viability.<br>
<br>
Many thanks,<br>
<br>
Matthieu Huin<br>
<br>
<a href="mailto:mhu@enovance.com" target="_blank">mhu@enovance.com</a><br>
<a href="http://www.enovance.com" target="_blank">http://www.enovance.com</a><br>
eNovance SaS - 10 rue de la Victoire 75009 Paris - France<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>
<br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></div><div><br></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>