<div dir="ltr">Thanks Adrian and Tim, I saw that @Vilobh already uploaded a patch <a href="https://review.openstack.org/#/c/259201/">https://review.openstack.org/#/c/259201/</a> here, perhaps we can first have a spec and discuss there. ;-) <br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 2:44 AM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-GB"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Given the lower level quotas in Heat, Neutron, Nova etc., the error feedback is very important. A Magnum “cannot create” message requires a lot of debugging whereas a “Floating IP quota exceeded” gives a clear root cause.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Whether we quota Magnum resources or not, some error scenarios and appropriate testing+documentation would be a great help for operators.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Tim<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue;padding:0cm 0cm 0cm 4pt"><div><div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) -moz-use-text-color -moz-use-text-color;padding:3pt 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif" lang="EN-US">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif" lang="EN-US"> Adrian Otto [mailto:<a href="mailto:adrian.otto@rackspace.com" target="_blank">adrian.otto@rackspace.com</a>] <br><b>Sent:</b> 20 December 2015 18:50<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>></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:12pt"><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:5pt;margin-bottom:5pt"><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><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><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:rgb(136,136,136)"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="color:rgb(136,136,136)">Lee<u></u><u></u></span></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><blockquote style="margin-top:5pt;margin-bottom:5pt"><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:5pt;margin-bottom:5pt;text-align:start;word-spacing:0px"><p class="MsoNormal" style="margin-bottom:12pt"><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><blockquote style="margin-top:5pt;margin-bottom:5pt"><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></blockquote><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><blockquote style="margin-top:5pt;margin-bottom:5pt"><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></blockquote><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><blockquote style="margin-top:5pt;margin-bottom:5pt"><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></blockquote><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><blockquote style="margin-top:5pt;margin-bottom:5pt"><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><blockquote style="margin-top:5pt;margin-bottom:5pt"><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></blockquote></blockquote><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><blockquote style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri",sans-serif">(i.e.<br><br><u></u><u></u></span></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><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></blockquote><p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri",sans-serif">resources.<br><br><u></u><u></u></span></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><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></blockquote></blockquote><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:5pt;margin-bottom:5pt"><blockquote style="margin-top:5pt;margin-bottom:5pt"><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></blockquote></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:12pt"><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></blockquote></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:12pt">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:5pt;margin-bottom:5pt"><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></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><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Thanks,<br><br></div>Jay Lau (Guangya Liu)<br></div></div></div></div>
</div></div></div>