<div dir="ltr"><font face="georgia, serif" color="#000000">Clint,</font><div><font face="georgia, serif" color="#000000"><br></font></div><div><font face="georgia, serif" color="#000000">To be more specific about the #2 option I was talking about is </font></div><div><font face="georgia, serif" color="#000000"><br></font></div><div><font face="georgia, serif" color="#000000">"<span style="font-stretch:normal"> </span><u></u>A request is within CaaS layer <span class="">quota</span>, and accepted by magnum. Magnum calls Heat to create a stack, which will fail if the stack exceeds IaaS layer <span class="">quota</span>. In this case, magnum catch and re-throw the exception to users."</font></div><div><font face="georgia, serif" color="#000000"><br></font></div><div><font face="georgia, serif" color="#000000">-Vilobh</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 22, 2015 at 6:58 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Jay Lau's message of 2015-12-21 22:29:14 -0800:<br>
<span class="">> For case 2), can we talk this with HEAT team? This seems to be a issue<br>
> related to HEAT quota, why HEAT do not add quota support?<br>
><br>
<br>
</span>It's been brought up before, and I made the same arguments against it<br>
there as I did here. I argued instead to focus on convergence, making Heat<br>
more scalable and more able to take on thousands of resources and stacks<br>
at once, which the team has been doing a great job at since I changed<br>
my focus. I'd be interested to hear if operators have been lamenting<br>
the lack of quotas in heat.<br>
<br>
BTW, in the quoted emails, there are multiple 2)'s. You should probably<br>
reply in-line so it is clear what you mean.<br>
<div><div class="h5"><br>
> On Tue, Dec 22, 2015 at 7:42 AM, Vilobh Meshram <<br>
> <a href="mailto:vilobhmeshram.openstack@gmail.com">vilobhmeshram.openstack@gmail.com</a>> wrote:<br>
><br>
> > As mentioned by Hongbin we might have these 3 cases. Hongbin and I did<br>
> > discuss about these in the Magnum IRC.<br>
> ><br>
> > The interestring case being the #2 one. Where in case enough resources are<br>
> > not available at the IaaS layer, and Magnum is in the process of creating a<br>
> > Bay; Magnum needs to be more descriptive about the failure so that the<br>
> > operator or user can be aware what exactly happened i.e. did the request<br>
> > failed because of resource constraints at the PaaS layer, at the IaaS layer<br>
> > etc.<br>
> ><br>
> > Having the Quota layer at magnum will abstract out the underlying layer<br>
> > and would impose quota on objects that Magnum understands. But again it<br>
> > would be nice to know what operators think about it and would it be<br>
> > something that they will find useful.<br>
> ><br>
> > -Vilobh<br>
> ><br>
> > On Mon, Dec 21, 2015 at 2:58 PM, Hongbin Lu <<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>> wrote:<br>
> ><br>
> >> If we decide to support quotas in CaaS layer (i.e. limit the # of bays),<br>
> >> its implementation doesn’t have to be redundant to IaaS layer (from Nova,<br>
> >> Cinder, etc.). The implementation could be a layer on top of IaaS, in which<br>
> >> requests need to pass two layers of quotas to succeed. There would be three<br>
> >> cases:<br>
> >><br>
> >> 1.       A request exceeds CaaS layer quota. Then, magnum rejects the<br>
> >> request.<br>
> >><br>
> >> 2.       A request is within CaaS layer quota, and accepted by magnum.<br>
> >> Magnum calls Heat to create a stack, which will fail if the stack exceeds<br>
> >> IaaS layer quota. In this case, magnum catch and re-throw the exception to<br>
> >> users.<br>
> >><br>
> >> 3.       A request is within both CaaS and IaaS layer quota, and the<br>
> >> request succeeds.<br>
> >><br>
> >><br>
> >><br>
> >> I think the debate here is whether it would be useful to implement an<br>
> >> extra layer of quota management system in Magnum. My guess is “yes”, if<br>
> >> operators want to hide the underline infrastructure, and expose a pure CaaS<br>
> >> solution to its end-users. If the operators don’t use Magnum in this way,<br>
> >> then I will vote for “no”.<br>
> >><br>
> >><br>
> >><br>
> >> Also, we can reference other platform-level services (like Trove and<br>
> >> Sahara) to see if they implemented an extra layer of quota management<br>
> >> system, and we could use it as a decision point.<br>
> >><br>
> >><br>
> >><br>
> >> Best regards,<br>
> >><br>
> >> Honbgin<br>
> >><br>
> >><br>
> >><br>
</div></div>> >> *From:* Adrian Otto [mailto:<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>]<br>
> >> *Sent:* December-20-15 12:50 PM<br>
> >> *To:* OpenStack Development Mailing List (not for usage questions)<br>
> >><br>
> >> *Subject:* Re: [openstack-dev] [openstack][magnum] Quota for Magnum<br>
<div class="HOEnZb"><div class="h5">> >> Resources<br>
> >><br>
> >><br>
> >><br>
> >> This sounds like a source-of-truth concern. From my perspective the<br>
> >> solution is not to create redundant quotas. Simply quota the Magnum<br>
> >> resources. Lower level limits *could* be queried by magnum prior to acting<br>
> >> to CRUD the lower level resources. In the case we could check the maximum<br>
> >> allowed number of (or access rate of) whatever lower level resource before<br>
> >> requesting it, and raising an understandable error. I see that as an<br>
> >> enhancement rather than a must-have. In all honesty that feature is<br>
> >> probably more complicated than it's worth in terms of value.<br>
> >><br>
> >> --<br>
> >><br>
> >> Adrian<br>
> >><br>
> >><br>
> >> On Dec 20, 2015, at 6:36 AM, Jay Lau <<a href="mailto:jay.lau.513@gmail.com">jay.lau.513@gmail.com</a>> wrote:<br>
> >><br>
> >> I also have the same concern with Lee, as Magnum depend on HEAT  and HEAT<br>
> >> need call nova, cinder, neutron to create the Bay resources. But both Nova<br>
> >> and Cinder has its own quota policy, if we define quota again in Magnum,<br>
> >> then how to handle the conflict? Another point is that limiting the Bay by<br>
> >> quota seems a bit coarse-grainded as different bays may have different<br>
> >> configuration and resource request. Comments? Thanks.<br>
> >><br>
> >><br>
> >><br>
> >> On Thu, Dec 17, 2015 at 4:10 AM, Lee Calcote <<a href="mailto:leecalcote@gmail.com">leecalcote@gmail.com</a>><br>
> >> wrote:<br>
> >><br>
> >> Food for thought - there is a cost to FIPs (in the case of public IP<br>
> >> addresses), security groups (to a lesser extent, but in terms of the<br>
> >> computation of many hundreds of them), etc. Administrators may wish to<br>
> >> enforce quotas on a variety of resources that are direct costs or indirect<br>
> >> costs (e.g. # of bays, where a bay consists of a number of multi-VM /<br>
> >> multi-host pods and services, which consume CPU, mem, etc.).<br>
> >><br>
> >><br>
> >><br>
> >> If Magnum quotas are brought forward, they should govern (enforce quota)<br>
> >> on Magnum-specific constructs only, correct? Resources created by Magnum<br>
> >> COEs should be governed by existing quota policies governing said resources<br>
> >> (e.g. Nova and vCPUs).<br>
> >><br>
> >><br>
> >><br>
> >> Lee<br>
> >><br>
> >><br>
> >><br>
> >> On Dec 16, 2015, at 1:56 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
> >><br>
> >><br>
> >><br>
> >> -----Original Message-----<br>
</div></div><div class="HOEnZb"><div class="h5">> >> From: Clint Byrum [mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a> <<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<br>
> >> pairs<br>
> >> which are not really real.<br>
> >><br>
> >><br>
> >> Memory, CPU, disk, bandwidth. These are all _closely_ tied to things that<br>
> >><br>
> >> cost<br>
> >><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>
> >><br>
> >> by real<br>
> >><br>
> >> things that they must pay for. If they have enough Nova quota to allocate<br>
> >><br>
> >> 1<br>
> >><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>
> >><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>
> >><br>
> >> is 5<br>
> >><br>
> >> (i.e.<br>
> >><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>
> >><br>
> >> resources.<br>
> >><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>
> >><br>
> >> k8s/COE.<br>
> >><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>
> >> __________<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>
> >> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
> >> ?subject:unsubscribe<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>
> >><br>
> >><br>
> >><br>
</div></div><span class="im HOEnZb">> >> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> >> <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>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >><br>
> >> Thanks,<br>
> >><br>
> >> Jay Lau (Guangya Liu)<br>
> >><br>
> >> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
</span><span class="im HOEnZb">> >> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
> >> ?subject:unsubscribe<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>
> >><br>
</span><div class="HOEnZb"><div class="h5">> >> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> >> <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>
> >><br>
> ><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>
> ><br>
><br>
<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>
</div></div></blockquote></div><br></div></div>