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 <mailto:cl...@fewbar.com>] >> Sent: 15 December 2015 22:40 >> To: openstack-dev <openstack-dev@lists.openstack.org >> <mailto: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 > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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
