<div dir="ltr"><font face="georgia, serif">As mentioned by Hongbin we might have these 3 cases. Hongbin and I did discuss about these in the Magnum IRC.</font><div><font face="georgia, serif"><br></font></div><div><font face="georgia, serif">The interestring case being the #2 one. Where in case enough resources are not available at the IaaS layer, and Magnum is in the process of creating a Bay; Magnum needs to be more descriptive about the failure so that the operator or user can be aware what exactly happened i.e. did the request failed because of resource constraints at the PaaS layer, at the IaaS layer etc.</font></div><div><font face="georgia, serif"><br></font></div><div><font face="georgia, serif">Having the Quota layer at magnum will abstract out the underlying layer and would impose quota on objects that Magnum understands. But again it would be nice to know what operators think about it and would it be something that they will find useful.</font></div><div><font face="georgia, serif"><br></font></div><div><font face="georgia, serif">-Vilobh<br></font><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 2:58 PM, Hongbin Lu <span dir="ltr"><<a href="mailto:hongbin.lu@huawei.com" target="_blank">hongbin.lu@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-CA" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If we decide to support quotas in CaaS layer (i.e. limit the # of bays), its implementation doesn’t have to be redundant to IaaS layer (from Nova, Cinder, etc.).
 The implementation could be a layer on top of IaaS, in which requests need to pass two layers of quotas to succeed. There would be three cases:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A request exceeds CaaS layer quota. Then, magnum rejects the request.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A request is within CaaS layer quota, and accepted by magnum. Magnum calls Heat to create a stack, which will fail if the stack exceeds IaaS layer
 quota. In this case, magnum catch and re-throw the exception to users.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A request is within both CaaS and IaaS layer quota, and the request succeeds.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think the debate here is whether it would be useful to implement an extra layer of quota management system in Magnum. My guess is “yes”, if operators want
 to hide the underline infrastructure, and expose a pure CaaS solution to its end-users. If the operators don’t use Magnum in this way, then I will vote for “no”.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Also, we can reference other platform-level services (like Trove and Sahara) to see if they implemented an extra layer of quota management system, and we could
 use it as a decision point.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Best regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Honbgin<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Adrian Otto [mailto:<a href="mailto:adrian.otto@rackspace.com" target="_blank">adrian.otto@rackspace.com</a>]
<br>
<b>Sent:</b> December-20-15 12:50 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)</span></p><div><div class="h5"><br>
<b>Subject:</b> Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">This sounds like a source-of-truth concern. From my perspective the solution is not to create redundant quotas. Simply quota the Magnum resources. Lower level limits *could* be queried by magnum prior to acting to CRUD the lower level resources.
 In the case we could check the maximum allowed number of (or access rate of) whatever lower level resource before requesting it, and raising an understandable error. I see that as an enhancement rather than a must-have. In all honesty that feature is probably
 more complicated than it's worth in terms of value.<br>
<br>
-- <u></u><u></u></p>
<div>
<p class="MsoNormal">Adrian<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Dec 20, 2015, at 6:36 AM, Jay Lau <<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">I also have the same concern with Lee, as Magnum depend on HEAT  and HEAT need call nova, cinder, neutron to create the Bay resources. But both Nova and Cinder has its own quota policy, if we define quota again in Magnum, then how to handle
 the conflict? Another point is that limiting the Bay by quota seems a bit coarse-grainded as different bays may have different configuration and resource request. Comments? Thanks.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Thu, Dec 17, 2015 at 4:10 AM, Lee Calcote <<a href="mailto:leecalcote@gmail.com" target="_blank">leecalcote@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">Food for thought - there is a cost to FIPs (in the case of public IP addresses), security groups (to a lesser extent, but in terms of the computation of many hundreds of them), etc. Administrators may wish to enforce quotas on a variety
 of resources that are direct costs or indirect costs (e.g. # of bays, where a bay consists of a number of multi-VM / multi-host pods and services, which consume CPU, mem, etc.).
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If Magnum quotas are brought forward, they should govern (enforce quota) on Magnum-specific constructs only, correct? Resources created by Magnum COEs should be governed by existing quota policies governing said resources (e.g. Nova and
 vCPUs).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Lee<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">On Dec 16, 2015, at 1:56 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;text-align:start;word-spacing:0px">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">-----Original Message-----<br>
From: Clint Byrum [<a href="mailto:clint@fewbar.com" target="_blank">mailto:clint@fewbar.com</a>]<br>
Sent: 15 December 2015 22:40<br>
To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">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.<u></u><u></u></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><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 style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">Memory, CPU, disk, bandwidth. These are all _closely_ tied to things that<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">cost<br style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">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<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">by real<br style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">things that they must pay for. If they have enough Nova quota to allocate<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">1<br style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">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>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">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<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">is 5<br style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">(i.e.<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">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<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">resources.<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><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<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">k8s/COE.<br style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><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" target="_blank">
https://blueprints.launchpad.net/magnum/+spec/resource-quota</a><u></u><u></u></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><br>
________________________________________________________________<br>
__________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-<br>
<a href="mailto:request@lists.openstack.org" target="_blank">request@lists.openstack.org</a>?subject:unsubscribe<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><u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </span><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">OpenStack-dev-request@lists.openstack.org</span></a><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">?subject:unsubscribe<br>
</span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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><u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Thanks,<u></u><u></u></p>
</div>
<p class="MsoNormal">Jay Lau (Guangya Liu)<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<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><u></u><u></u></p>
</div>
</blockquote>
</div></div></div>
</div>

<br>__________________________________________________________________________<br>
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>
<br></blockquote></div><br></div></div></div>