Clint, > On Dec 16, 2015, at 11:56 AM, Tim Bell <tim.b...@cern.ch> wrote: > >> -----Original Message----- >> From: Clint Byrum [mailto: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.
No. Beyond billable resources, quotas are a mechanism for limiting abusive use patterns from hostile users. The rate at which Bays are created, and how many of them you can have in total are important limits to put in the hands of cloud operators. Each Bay contains a keypair, which takes resources to generate and securely distribute. Updates to and Deletion of bays causes a storm of activity in Heat, and even more activity in Nova. Cloud operators should have the ability to control the rate of activity by enforcing rate controls on Magnum resources before they become problematic further down in the control plane. Admission controls are best managed at the entrance to a system, not at the core. Adrian > 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
