Open Stack

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.Bell at cern.ch> wrote:
> 
>> -----Original Message-----
>> From: Clint Byrum [mailto:clint at fewbar.com <mailto:clint at fewbar.com>]
>> Sent: 15 December 2015 22:40
>> To: openstack-dev <openstack-dev at lists.openstack.org <mailto:openstack-dev at 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-
>> request at 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-request at lists.openstack.org <mailto:OpenStack-dev-request at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151216/6b3ef9a9/attachment.html>