08:04:12 <joehuang> #startmeeting multisite
08:04:12 <collabot`> Meeting started Thu Mar  3 08:04:12 2016 UTC.  The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:04:12 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:04:12 <collabot`> The meeting name has been set to 'multisite'
08:04:19 <SAshish> #info Ashish
08:04:27 <joehuang> #info joehuang
08:04:39 <sorantis> #info dimitri
08:05:02 <joehuang> let's discuss quota api
08:05:09 <SAshish> yeah. please. https://review.openstack.org/#/c/284137/2/kingbird/api/README.rst
08:05:28 <joehuang> I have some comments on Ashish patch about API
08:05:48 <SAshish> I have replied to few of them
08:05:54 <SAshish> let us discuss those
08:06:02 <joehuang> Yes
08:06:34 <joehuang> May I introduce a little about quota in Nova,Cinder about the default quota
08:06:59 <SAshish> sure.
08:07:03 <joehuang> sorry. May I introduce a little about default quota in Nova,Cinder
08:07:25 <joehuang> At first, the default quota is configured in the configuration file
08:07:45 <joehuang> but later, it's difficult to change default quota
08:07:47 <SAshish> this default quota is for all the tenants
08:07:58 <SAshish> generic quota
08:08:05 <SAshish> or global quota
08:08:17 <joehuang> for example, API can run multiple instances
08:08:38 <joehuang> so if you change one file, the other one is not changed yet
08:09:22 <joehuang> In Nova and Cinder, use quota_class to define the default quota, so that the default quota is easy to change
08:09:51 <joehuang> and can bring different default quota for different level tenants
08:10:08 <joehuang> for example, "golden class" can have 100 instances
08:10:30 <joehuang> but for "metal class" the default may be 10
08:11:02 <SAshish> is that this cuztomised quota for a tenant
08:11:06 <joehuang> but currently, almost the classification of default quota is not used
08:11:09 <SAshish> isnt this*
08:11:22 <joehuang> only "default" class is used
08:11:40 <joehuang> no, it's customization for "default" value
08:11:42 <sorantis> customized quota is stored in the quota table
08:11:55 <sorantis> classes on the other hand are in quota_classes
08:11:55 <joehuang> yes, Dimitri is right
08:12:03 <joehuang> correct
08:12:09 <sorantis> which we currently don’t have from the db point of view
08:12:20 <sorantis> this needs to be added in that case
08:12:33 <joehuang> but in fact, only "default" class has been used currently
08:12:52 <joehuang> and the default quota by configuration is deprecated way of using
08:13:02 <SAshish> okay
08:13:39 <sorantis> i can add a db layer for it
08:14:16 <joehuang> if you change the default value in the quota-class, all project's default value will be changed
08:14:22 <joehuang> great
08:15:42 <joehuang> so the question is do we need to provide api for quota_class ?
08:16:25 <joehuang> In nova/cinder, if there is some value in quota_class, then this value will be used by priority
08:16:58 <sorantis> in the long run I would like to have kb to support quotas the way other services do
08:17:04 <joehuang> but if no data in quota_class, configuration default value will be used instead, although it's deprecated
08:17:20 <sorantis> so that it was easier for everyone to switch to kb as quota records repository
08:17:42 <joehuang> agree, we can add step by step
08:17:42 <sorantis> I’m not sure that quota classes are used widely
08:17:50 <sorantis> haven’t seen this to be honest
08:17:53 <SAshish> if we maintain quotas in kb DB, then we need not depend on neutron
08:18:00 <SAshish> as neutron doesnot have this
08:18:20 <sorantis> neutron is a special case, i agree
08:18:51 <sorantis> there will be no classes for neutron related limits
08:19:38 <sorantis> so I would suggest to have the quota API layer the same as in Cinder/Nova
08:19:39 <joehuang> ok, this is some background for reference
08:20:10 <sorantis> focus on finishing quota management part and see that it runs for once
08:20:23 <joehuang> +1 to dimitri
08:20:31 <sorantis> then, as a next step we can start landing quota classes patches
08:20:34 <sorantis> and so on
08:20:46 <sorantis> we can’t grab everything in one go
08:21:20 <joehuang> That's why I hope not to provide quota post, to keep alignment to other services as much as possible
08:21:44 <sorantis> I suggested Ashish to reuse the API reference from Cinder as much as possible
08:22:07 <joehuang> no quota "post" in other services, only "put" to update quota
08:22:15 <SAshish> yes. For the structure I have followed that
08:22:41 <SAshish> update has to happen in DB in our case
08:23:03 <sorantis> Ashish, can you change your patch to reflect what we’ve talked about?
08:23:39 <joehuang> You mean quota "post"?
08:24:00 <joehuang> DB can be update by "put" too
08:24:01 <sorantis> that too
08:24:13 <SAshish> okay.
08:24:23 <sorantis> but also update the API reference
08:24:43 <SAshish> apiary??
08:24:54 <sorantis> no that later
08:25:01 <sorantis> I mean use this format
08:25:11 <sorantis> http://developer.openstack.org/api-ref-blockstorage-v2.html#os-quota-sets-v2
08:25:16 <sorantis> or at least similar
08:25:44 <SAshish> yeah.. we have the same..
08:25:47 <SAshish> in current patch
08:26:18 <joehuang> format is almost same
08:26:29 <SAshish> https://review.openstack.org/#/c/284137/2/kingbird/api/README.rst
08:26:36 <SAshish> please refer the API structure here
08:26:56 <SAshish> I will remove post API
08:27:20 <SAshish> using put I will create/update limits
08:27:28 <joehuang> and delete specific resource's quota value
08:27:49 <joehuang> no this interface in other services, do we need to add this one?
08:28:57 <SAshish> If there are multiple quota limits and you want to delete only one limit
08:29:04 <SAshish> one or few of themm
08:29:18 <SAshish> I felt its need so kept it
08:29:36 <joehuang> ok
08:29:50 <SAshish> #info remove post API request
08:30:28 <SAshish> delete is not to delete quota record, but to restore it to default quota
08:30:40 <joehuang> other to discuss?
08:31:10 <SAshish> yes. delete will remove from DB, so that defaults from conf will be used
08:31:18 <joehuang> +1
08:31:20 <SAshish> the preference is like this first check in DB
08:31:26 <SAshish> if not then in conf
08:31:28 <SAshish> okay
08:31:55 <SAshish> 1) http://127.0.0.1:8118/v1.0/admin_tenant_id/os-quota-sets/tenant1/defaults  this one will get the default quota
08:31:59 <SAshish> this one
08:32:12 <sorantis> joe, we should clarify the talks
08:32:22 <sorantis> but we can take it later
08:33:33 <joehuang> if we follow cinder, no "http://127.0.0.1:8118/v1.0/admin_tenant_id/os-quota-sets/tenant1/defaults" api
08:33:37 <SAshish> this is the API reference for getting default    /v2/​{tenant_id}​/os-quota-sets/defaults
08:34:22 <SAshish> for cinder it is /v2/​{tenant_id}​/os-quota-sets/defaults
08:34:22 <joehuang> ok, follow Cinder. Nova has a little bit different API for defaults
08:34:27 <joehuang> yes
08:34:35 <SAshish> yes.
08:34:48 <joehuang> For nova, it's the first one you mentioned
08:35:11 <joehuang> sometimes it annoy
08:35:28 <SAshish> yes.
08:35:44 <SAshish> can you tell me the use of admin_tenant_id in API
08:36:00 <SAshish> don't we have to validate it
08:36:06 <SAshish> ?
08:38:01 <joehuang> It's often validate the admin role in context, seldom to see to compare the tenant_id with cfg.CONF
08:38:32 <SAshish> then admin_tenant_id is not of much significance here
08:39:29 <joehuang> it's useful in hierarchy multitenancy quota, will check to see if admin_tenant_id is the parent of tenant_id
08:39:42 <joehuang> through query the data from keystone
08:40:08 <joehuang> we need to pass this id to other region Cinder, Nova
08:40:12 <SAshish> okay. thanks
08:40:43 <joehuang> it's useful :)
08:40:51 <SAshish> yes. it is
08:41:02 <SAshish> I will be pushing on demand quota sync for a project soon
08:41:06 <SAshish> also periodic quota sync
08:41:23 <joehuang> any other question on my comment?
08:41:46 <SAshish> but for now It will be only w.r.t nova resources, let us first get nova syncing in then will add cinder and neutron
08:42:29 <SAshish> periodic/OnDemand quota sync related to nova resources.
08:42:47 <joehuang> step by step, ROMA is not built in one day
08:43:05 <SAshish> hahah. yes. No questions on your comments
08:43:37 <joehuang> other topics
08:43:43 <sorantis> i suggest we close here
08:44:00 <joehuang> ok, thanks for your time. Great to work with you
08:44:20 <SAshish> welcome. Same here:)
08:44:22 <joehuang> Hi Dimitri, check your mail for the talk update in OpenStack summit
08:44:37 <SAshish> did we get it?
08:44:58 <SAshish> they mentioned it will be in first week on March
08:45:12 <joehuang> another topic, needs merge with some other topic, and update the abstract needed
08:45:12 <SAshish> any update ?
08:45:36 <joehuang> may be by the weekend
08:45:54 <joehuang> ok bye
08:45:59 <joehuang> #endmeeting