Re: [openstack-dev] [openstack][magnum][heat] Quota for Magnum Resources
Thanks Vilobh and Clint! @Clint, Yes, what I meant for #2 is exactly as Vilobh mentioned "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." If HEAT can support quota's, then all of other services who is consuming HEAT can easily have Quota enabled, such as Magnum, Murano, Sahara etc. What do you say? Is it possible to add Quota to HEAT? Thanks! On Wed, Dec 23, 2015 at 2:56 AM, Vilobh Meshram < vilobhmeshram.openst...@gmail.com> wrote: > Clint, > > To be more specific about the #2 option I was talking about is > > " 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." > > -Vilobh > > On Tue, Dec 22, 2015 at 6:58 AM, Clint Byrum wrote: > >> Excerpts from Jay Lau's message of 2015-12-21 22:29:14 -0800: >> > For case 2), can we talk this with HEAT team? This seems to be a issue >> > related to HEAT quota, why HEAT do not add quota support? >> > >> >> It's been brought up before, and I made the same arguments against it >> there as I did here. I argued instead to focus on convergence, making Heat >> more scalable and more able to take on thousands of resources and stacks >> at once, which the team has been doing a great job at since I changed >> my focus. I'd be interested to hear if operators have been lamenting >> the lack of quotas in heat. >> >> BTW, in the quoted emails, there are multiple 2)'s. You should probably >> reply in-line so it is clear what you mean. >> >> > On Tue, Dec 22, 2015 at 7:42 AM, Vilobh Meshram < >> > vilobhmeshram.openst...@gmail.com> wrote: >> > >> > > As mentioned by Hongbin we might have these 3 cases. Hongbin and I did >> > > discuss about these in the Magnum IRC. >> > > >> > > 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. >> > > >> > > 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. >> > > >> > > -Vilobh >> > > >> > > On Mon, Dec 21, 2015 at 2:58 PM, Hongbin Lu >> wrote: >> > > >> > >> 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: >> > >> >> > >> 1. A request exceeds CaaS layer quota. Then, magnum rejects the >> > >> request. >> > >> >> > >> 2. 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. >> > >> >> > >> 3. A request is within both CaaS and IaaS layer quota, and the >> > >> request succeeds. >> > >> >> > >> >> > >> >> > >> 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”. >> > >> >> > >> >> > >> >> > >> 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. >> > >> >> > >> >> > >> >> > >> Best regards, >> > >> >> > >> Honbgin >> > >> >> > >> >> > >> >> > >> *From:* Adrian Otto [mailto:adrian.o...@rackspace.com] >> > >> *Sent:* December-20-15 12:50 PM >> > >> *To:* OpenStack Development Mailing List (not for usage questions) >> > >> >> > >> *Subject:* Re: [openstack-dev] [openstack][magnum] Quota for Magnum >> > >> Resources >> > >> >> > >> >> > >> >> > >> 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 >> > >> al
Re: [openstack-dev] [openstack][magnum][heat] Quota for Magnum Resources
Clint, To be more specific about the #2 option I was talking about is " 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." -Vilobh On Tue, Dec 22, 2015 at 6:58 AM, Clint Byrum wrote: > Excerpts from Jay Lau's message of 2015-12-21 22:29:14 -0800: > > For case 2), can we talk this with HEAT team? This seems to be a issue > > related to HEAT quota, why HEAT do not add quota support? > > > > It's been brought up before, and I made the same arguments against it > there as I did here. I argued instead to focus on convergence, making Heat > more scalable and more able to take on thousands of resources and stacks > at once, which the team has been doing a great job at since I changed > my focus. I'd be interested to hear if operators have been lamenting > the lack of quotas in heat. > > BTW, in the quoted emails, there are multiple 2)'s. You should probably > reply in-line so it is clear what you mean. > > > On Tue, Dec 22, 2015 at 7:42 AM, Vilobh Meshram < > > vilobhmeshram.openst...@gmail.com> wrote: > > > > > As mentioned by Hongbin we might have these 3 cases. Hongbin and I did > > > discuss about these in the Magnum IRC. > > > > > > 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. > > > > > > 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. > > > > > > -Vilobh > > > > > > On Mon, Dec 21, 2015 at 2:58 PM, Hongbin Lu > wrote: > > > > > >> 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: > > >> > > >> 1. A request exceeds CaaS layer quota. Then, magnum rejects the > > >> request. > > >> > > >> 2. 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. > > >> > > >> 3. A request is within both CaaS and IaaS layer quota, and the > > >> request succeeds. > > >> > > >> > > >> > > >> 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”. > > >> > > >> > > >> > > >> 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. > > >> > > >> > > >> > > >> Best regards, > > >> > > >> Honbgin > > >> > > >> > > >> > > >> *From:* Adrian Otto [mailto:adrian.o...@rackspace.com] > > >> *Sent:* December-20-15 12:50 PM > > >> *To:* OpenStack Development Mailing List (not for usage questions) > > >> > > >> *Subject:* Re: [openstack-dev] [openstack][magnum] Quota for Magnum > > >> Resources > > >> > > >> > > >> > > >> 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. > > >> > > >> -- > > >> > > >> Adrian > > >> > > >> > > >> On Dec 20, 2015, at 6:36 AM, Jay Lau wrote: > > >> > > >> 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
Re: [openstack-dev] [openstack][magnum][heat] Quota for Magnum Resources
Excerpts from Jay Lau's message of 2015-12-21 22:29:14 -0800: > For case 2), can we talk this with HEAT team? This seems to be a issue > related to HEAT quota, why HEAT do not add quota support? > It's been brought up before, and I made the same arguments against it there as I did here. I argued instead to focus on convergence, making Heat more scalable and more able to take on thousands of resources and stacks at once, which the team has been doing a great job at since I changed my focus. I'd be interested to hear if operators have been lamenting the lack of quotas in heat. BTW, in the quoted emails, there are multiple 2)'s. You should probably reply in-line so it is clear what you mean. > On Tue, Dec 22, 2015 at 7:42 AM, Vilobh Meshram < > vilobhmeshram.openst...@gmail.com> wrote: > > > As mentioned by Hongbin we might have these 3 cases. Hongbin and I did > > discuss about these in the Magnum IRC. > > > > 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. > > > > 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. > > > > -Vilobh > > > > On Mon, Dec 21, 2015 at 2:58 PM, Hongbin Lu wrote: > > > >> 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: > >> > >> 1. A request exceeds CaaS layer quota. Then, magnum rejects the > >> request. > >> > >> 2. 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. > >> > >> 3. A request is within both CaaS and IaaS layer quota, and the > >> request succeeds. > >> > >> > >> > >> 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”. > >> > >> > >> > >> 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. > >> > >> > >> > >> Best regards, > >> > >> Honbgin > >> > >> > >> > >> *From:* Adrian Otto [mailto:adrian.o...@rackspace.com] > >> *Sent:* December-20-15 12:50 PM > >> *To:* OpenStack Development Mailing List (not for usage questions) > >> > >> *Subject:* Re: [openstack-dev] [openstack][magnum] Quota for Magnum > >> Resources > >> > >> > >> > >> 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. > >> > >> -- > >> > >> Adrian > >> > >> > >> On Dec 20, 2015, at 6:36 AM, Jay Lau wrote: > >> > >> 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. > >> > >> > >> > >> On Thu, Dec 17, 2015 at 4:10 AM, Lee Calcote > >> wrote: > >> > >> 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 pod
