The intent here in Magnum is to enforce quota on resources owned by Magnum (#of bays etc that are allowed to be created for a user in a project).
+1 to Lee that "Resources created by Magnum COEs should be governed by existing quota policies governing said resources (e.g. Nova and vCPUs).". -Vilobh On Wed, Dec 16, 2015 at 12:19 PM, Fox, Kevin M <[email protected]> wrote: > keypairs are real though. they consume database resource at the moment. > You don't want a user blowing out your db. Quota's should be for things > that ops will get sad over, if the users consume too many of them. > > Thanks, > Kevin > ________________________________________ > From: Tim Bell [[email protected]] > Sent: Wednesday, December 16, 2015 11:56 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources > > > -----Original Message----- > > From: Clint Byrum [mailto:[email protected]] > > Sent: 15 December 2015 22:40 > > To: openstack-dev <[email protected]> > > 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- > > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
