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?
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 <hongbin...@huawei.com> 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 <jay.lau....@gmail.com> 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 <leecalc...@gmail.com> >> 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 pods and services, which consume CPU, mem, etc.). >> >> >> >> 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). >> >> >> >> Lee >> >> >> >> On Dec 16, 2015, at 1:56 PM, Tim Bell <tim.b...@cern.ch> wrote: >> >> >> >> -----Original Message----- >> From: Clint Byrum [mailto:cl...@fewbar.com <cl...@fewbar.com>] >> Sent: 15 December 2015 22:40 >> To: openstack-dev <openstack-dev@lists.openstack.org> >> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum >> Resources >> >> Hi! Can I offer a counter point? >> >> Quotas are for _real_ resources. >> >> >> The CERN container specialist agrees with you ... it would be good to >> reflect on the needs given that ironic, neutron and nova are policing the >> resource usage. Quotas in the past have been used for things like key >> pairs >> which are not really real. >> >> >> Memory, CPU, disk, bandwidth. These are all _closely_ tied to things that >> >> cost >> >> real money and cannot be conjured from thin air. As such, the user being >> able to allocate 1 billion or 2 containers is not limited by Magnum, but >> >> by real >> >> things that they must pay for. If they have enough Nova quota to allocate >> >> 1 >> >> billion tiny pods, why would Magnum stop them? Who actually benefits from >> that limitation? >> >> So I suggest that you not add any detailed, complicated quota system to >> Magnum. If there are real limitations to the implementation that Magnum >> has chosen, such as we had in Heat (the entire stack must fit in memory), >> then make that the limit. Otherwise, let their vcpu, disk, bandwidth, and >> memory quotas be the limit, and enjoy the profit margins that having an >> unbound force multiplier like Magnum in your cloud gives you and your >> users! >> >> Excerpts from Vilobh Meshram's message of 2015-12-14 16:58:54 -0800: >> >> Hi All, >> >> Currently, it is possible to create unlimited number of resource like >> bay/pod/service/. In Magnum, there should be a limitation for user or >> project to create Magnum resource, and the limitation should be >> configurable[1]. >> >> I proposed following design :- >> >> 1. Introduce new table magnum.quotas >> +------------+--------------+------+-----+---------+----------------+ >> >> | Field | Type | Null | Key | Default | Extra | >> >> +------------+--------------+------+-----+---------+----------------+ >> >> | id | int(11) | NO | PRI | NULL | auto_increment | >> >> | created_at | datetime | YES | | NULL | | >> >> | updated_at | datetime | YES | | NULL | | >> >> | deleted_at | datetime | YES | | NULL | | >> >> | project_id | varchar(255) | YES | MUL | NULL | | >> >> | resource | varchar(255) | NO | | NULL | | >> >> | hard_limit | int(11) | YES | | NULL | | >> >> | deleted | int(11) | YES | | NULL | | >> >> +------------+--------------+------+-----+---------+----------------+ >> >> resource can be Bay, Pod, Containers, etc. >> >> >> 2. API controller for quota will be created to make sure basic CLI >> commands work. >> >> quota-show, quota-delete, quota-create, quota-update >> >> 3. When the admin specifies a quota of X number of resources to be >> created the code should abide by that. For example if hard limit for Bay >> >> is 5 >> >> (i.e. >> >> a project can have maximum 5 Bay's) if a user in a project tries to >> exceed that hardlimit it won't be allowed. Similarly goes for other >> >> resources. >> >> >> 4. Please note the quota validation only works for resources created >> via Magnum. Could not think of a way that Magnum to know if a COE >> specific utilities created a resource in background. One way could be >> to see the difference between whats stored in magnum.quotas and the >> information of the actual resources created for a particular bay in >> >> k8s/COE. >> >> >> 5. Introduce a config variable to set quotas values. >> >> If everyone agrees will start the changes by introducing quota >> restrictions on Bay creation. >> >> Thoughts ?? >> >> >> -Vilobh >> >> [1] https://blueprints.launchpad.net/magnum/+spec/resource-quota >> >> >> ________________________________________________________________ >> __________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev- >> requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org >> ?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> >> Thanks, >> >> Jay Lau (Guangya Liu) >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org >> ?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Thanks, Jay Lau (Guangya Liu)
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
