<div dir="ltr">The intent here in Magnum is to enforce quota on resources owned by Magnum (#of bays etc that are allowed to be created for a user in a project). <div><br></div><div>+1 to Lee that "<span style="font-size:12.8px">Resources created by Magnum COEs should be governed by existing quota policies governing said resources (e.g. Nova and vCPUs).".</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">-Vilobh</span></div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 12:19 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">keypairs are real though. they consume database resource at the moment. You don't want a user blowing out your db. Quota's should be for things that ops will get sad over, if the users consume too many of them.<br>
<br>
Thanks,<br>
Kevin<br>
________________________________________<br>
From: Tim Bell [<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>]<br>
Sent: Wednesday, December 16, 2015 11:56 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
<div><div class="h5">Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources<br>
<br>
> -----Original Message-----<br>
> From: Clint Byrum [mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>]<br>
> Sent: 15 December 2015 22:40<br>
> To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum<br>
> Resources<br>
><br>
> Hi! Can I offer a counter point?<br>
><br>
> Quotas are for _real_ resources.<br>
><br>
<br>
The CERN container specialist agrees with you ... it would be good to<br>
reflect on the needs given that ironic, neutron and nova are policing the<br>
resource usage. Quotas in the past have been used for things like key pairs<br>
which are not really real.<br>
<br>
> Memory, CPU, disk, bandwidth. These are all _closely_ tied to things that<br>
cost<br>
> real money and cannot be conjured from thin air. As such, the user being<br>
> able to allocate 1 billion or 2 containers is not limited by Magnum, but<br>
by real<br>
> things that they must pay for. If they have enough Nova quota to allocate<br>
1<br>
> billion tiny pods, why would Magnum stop them? Who actually benefits from<br>
> that limitation?<br>
><br>
> So I suggest that you not add any detailed, complicated quota system to<br>
> Magnum. If there are real limitations to the implementation that Magnum<br>
> has chosen, such as we had in Heat (the entire stack must fit in memory),<br>
> then make that the limit. Otherwise, let their vcpu, disk, bandwidth, and<br>
> memory quotas be the limit, and enjoy the profit margins that having an<br>
> unbound force multiplier like Magnum in your cloud gives you and your<br>
> users!<br>
><br>
> Excerpts from Vilobh Meshram's message of 2015-12-14 16:58:54 -0800:<br>
> > Hi All,<br>
> ><br>
> > Currently, it is possible to create unlimited number of resource like<br>
> > bay/pod/service/. In Magnum, there should be a limitation for user or<br>
> > project to create Magnum resource, and the limitation should be<br>
> > configurable[1].<br>
> ><br>
> > I proposed following design :-<br>
> ><br>
> > 1. Introduce new table magnum.quotas<br>
> > +------------+--------------+------+-----+---------+----------------+<br>
> ><br>
> > | Field | Type | Null | Key | Default | Extra |<br>
> ><br>
> > +------------+--------------+------+-----+---------+----------------+<br>
> ><br>
> > | id | int(11) | NO | PRI | NULL | auto_increment |<br>
> ><br>
> > | created_at | datetime | YES | | NULL | |<br>
> ><br>
> > | updated_at | datetime | YES | | NULL | |<br>
> ><br>
> > | deleted_at | datetime | YES | | NULL | |<br>
> ><br>
> > | project_id | varchar(255) | YES | MUL | NULL | |<br>
> ><br>
> > | resource | varchar(255) | NO | | NULL | |<br>
> ><br>
> > | hard_limit | int(11) | YES | | NULL | |<br>
> ><br>
> > | deleted | int(11) | YES | | NULL | |<br>
> ><br>
> > +------------+--------------+------+-----+---------+----------------+<br>
> ><br>
> > resource can be Bay, Pod, Containers, etc.<br>
> ><br>
> ><br>
> > 2. API controller for quota will be created to make sure basic CLI<br>
> > commands work.<br>
> ><br>
> > quota-show, quota-delete, quota-create, quota-update<br>
> ><br>
> > 3. When the admin specifies a quota of X number of resources to be<br>
> > created the code should abide by that. For example if hard limit for Bay<br>
is 5<br>
> (i.e.<br>
> > a project can have maximum 5 Bay's) if a user in a project tries to<br>
> > exceed that hardlimit it won't be allowed. Similarly goes for other<br>
> resources.<br>
> ><br>
> > 4. Please note the quota validation only works for resources created<br>
> > via Magnum. Could not think of a way that Magnum to know if a COE<br>
> > specific utilities created a resource in background. One way could be<br>
> > to see the difference between whats stored in magnum.quotas and the<br>
> > information of the actual resources created for a particular bay in<br>
k8s/COE.<br>
> ><br>
> > 5. Introduce a config variable to set quotas values.<br>
> ><br>
> > If everyone agrees will start the changes by introducing quota<br>
> > restrictions on Bay creation.<br>
> ><br>
> > Thoughts ??<br>
> ><br>
> ><br>
> > -Vilobh<br>
> ><br>
> > [1] <a href="https://blueprints.launchpad.net/magnum/+spec/resource-quota" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/magnum/+spec/resource-quota</a><br>
><br>
> ________________________________________________________________<br>
> __________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div>__________________________________________________________________________<br>
<div class="HOEnZb"><div class="h5">OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>