Vilobh/Tim, could you elaborate about your use-cases around Magnum quota? My concern is that user will be easy lost in quotas ;). e.g. we already have nova/cinder/neutron and Kub/Mesos(Framework) quotas.
There are two use-cases: - tenant has it’s own list of bays/clusters (nova/cinder/neutron quota will apply) - operator provision shared cluster and relay at Kub/Mesos(Framework) quota management Also user full access to native tools (Kub/Marathon/Swarm), how quota will be applied in this case? — Egor From: Vilobh Meshram <[email protected]<mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Date: Tuesday, December 15, 2015 at 11:11 To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Cc: "OpenStack Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>>, Belmiro Moreira <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources IMHO for Magnum and Nested Quota we need more discussion before proceeding ahead because :- 1. The main intent of hierarchical multi tenancy is creating a hierarchy of projects (so that its easier for the cloud provider to manage different projects) and nested quota driver being able to validate and impose those restrictions. 2. The tenancy boundary in Magnum is the bay. Bays offer both a management and security isolation between multiple tenants. 3. In Magnum there is no intent to share a single bay between multiple tenants. So I would like to have a discussion on whether Nested Quota approach fits in our/Magnum's design and how will the resources be distributed in the hierarchy. I will include it in our Magnum weekly meeting agenda. I have in-fact drafted a blueprint for it sometime back [1]. I am a huge supporter of hierarchical projects and nested quota approaches (as they if done correctly IMHO minimize admin pain of managing quotas) , just wanted to see a cleaner way we can get this done for Magnum. JFYI, I am the primary author of Cinder Nested Quota [2] and co-author of Nova Nested Quota[3] so I am familiar with the approach taken in both. Thoughts ? -Vilobh [1] Magnum Nested Quota : https://blueprints.launchpad.net/magnum/+spec/nested-quota-magnum [2] Cinder Nested Quota Driver : https://review.openstack.org/#/c/205369/ [3] Nova Nested Quota Driver : https://review.openstack.org/#/c/242626/ On Tue, Dec 15, 2015 at 10:10 AM, Tim Bell <[email protected]<mailto:[email protected]>> wrote: Thanks… it is really important from the user experience that we keep the nested quota implementations in sync so we don’t have different semantics. Tim From: Adrian Otto [mailto:[email protected]<mailto:[email protected]>] Sent: 15 December 2015 18:44 To: OpenStack Development Mailing List (not for usage questions) <[email protected]<mailto:[email protected]>> Cc: OpenStack Mailing List (not for usage questions) <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources Vilobh, Thanks for advancing this important topic. I took a look at what Tim referenced how Nova is implementing nested quotas, and it seems to me that’s something we could fold in as well to our design. Do you agree? Adrian On Dec 14, 2015, at 10:22 PM, Tim Bell <[email protected]<mailto:[email protected]>> wrote: Can we have nested project quotas in from the beginning ? Nested projects are in Keystone V3 from Kilo onwards and retrofitting this is hard work. For details, see the Nova functions at https://review.openstack.org/#/c/242626/. Cinder now also has similar functions. Tim From: Vilobh Meshram [mailto:[email protected]] Sent: 15 December 2015 01:59 To: OpenStack Development Mailing List (not for usage questions) <[email protected]<mailto:[email protected]>>; OpenStack Mailing List (not for usage questions) <[email protected]<mailto:[email protected]>> Subject: [openstack-dev] [openstack][magnum] Quota for Magnum Resources 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: [email protected]<mailto:[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://[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
