Open Stack

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 <Kevin.Fox at pnnl.gov> 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 [Tim.Bell at cern.ch]
> 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:clint at fewbar.com]
> > Sent: 15 December 2015 22:40
> > To: openstack-dev <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?subject:unsubscribe
> 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/30ac8cea/attachment.html>