Thanks Adrian and Tim, I saw that @Vilobh already uploaded a patch https://review.openstack.org/#/c/259201/ here, perhaps we can first have a spec and discuss there. ;-)
On Mon, Dec 21, 2015 at 2:44 AM, Tim Bell <tim.b...@cern.ch> wrote: > Given the lower level quotas in Heat, Neutron, Nova etc., the error > feedback is very important. A Magnum “cannot create” message requires a lot > of debugging whereas a “Floating IP quota exceeded” gives a clear root > cause. > > > > Whether we quota Magnum resources or not, some error scenarios and > appropriate testing+documentation would be a great help for operators. > > > > Tim > > > > *From:* Adrian Otto [mailto:adrian.o...@rackspace.com] > *Sent:* 20 December 2015 18:50 > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > > *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 > > -- 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
