16:04:18 #startmeeting HierarchicalMultitenancy 16:04:19 Meeting started Fri Nov 21 16:04:18 2014 UTC and is due to finish in 60 minutes. The chair is raildo. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:04:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:04:24 The meeting name has been set to 'hierarchicalmultitenancy' 16:05:03 I created this wiki to organize the meeting 16:05:09 #link https://wiki.openstack.org/wiki/Meetings/HierarchicalMultitenancyMeeting 16:05:12 ok 16:05:47 so, we can create the agenda to the meeting 16:06:10 #topic morganfainberg Notes about HM 16:06:19 #link https://www.morganfainberg.com/blog/2014/11/12/kilo-summit-summary/#hm 16:06:57 So, he make a good summary that we discuss in the Summit and the next steps about Hierachical Multitenancy 16:07:08 ok 16:07:14 Please read it as soon as possible :) 16:08:21 nirupma, did you update your team about the summit? 16:08:43 i did tell them all i could remember 16:08:51 nirupma, great 16:09:22 #topic Hierarchical Multitenancy Improvements Spec 16:09:32 #link https://review.openstack.org/#/c/135309/ 16:10:10 We started the new spec about HM 16:10:19 ok 16:10:52 so we'll implement new features like recursive deletion, new ways to return the projects 16:11:33 ok 16:11:49 I'll wait for feedback :) 16:12:04 sure :-) 16:12:59 #topic Quota Management Design Session summary 16:13:06 gabriel-bezerra, ? 16:13:14 hi 16:13:17 #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg39958.html 16:13:33 raildo: may I get back to the previous topic for a second? 16:13:44 abrito, sure 16:14:30 one interesting question would be to ask what are the views about the most important "next-features" in HM... 16:15:12 in the spec, we covered just deletion, "hierarchy-preserving" get and the change of the policy 16:15:27 right 16:15:52 is there any other priorities? 16:15:57 *are* 16:17:22 abrito, yes, We have other features related to the projects and domains visibility. So we can create private projects, and cover the Reseller Use Case 16:18:14 the ideia is if a give a project to a user, he can change this project to be a domain, and he can control the users, roles and groups 16:18:36 is that going into the HM spec? 16:19:11 abrito, no, we are create other spec to explain this implementation, that a "reseller use case" spec 16:19:32 ok 16:19:42 but we need to work together henrynash in this another spec: https://review.openstack.org/#/c/133855/ 16:20:05 that is add support for groups of roles. 16:21:23 so, I believe that with this 3 spec, we can make the Multitenancy concept very strong in the Openstack 16:22:21 ok, thank you 16:22:31 raildo,one quick question about the spec, the o/p of GET /projects/{project_id}?parents_ids ...is it parent heirarchy up to the root project? 16:23:16 sajeesh, yes. we are implementing two ways do get the hierarchy 16:23:24 ok 16:23:52 so the first: we have a GET /projects/{project_id}?parents_as_list (and the same for the subtree) 16:24:05 ok 16:24:55 that is the same implementation that we have now, when we'll return a list of projects, with the whole information about the project 16:25:04 right 16:25:38 but,right we have it only for subtree..not for parents...right ? 16:25:43 right now 16:25:57 and we are implementing a new implementation, that GET /projects/{project_id}?parents_ids when we'll return a projects_ids dictionaries, (just the projects_ids) 16:25:59 we have it for parents as well 16:26:04 ok 16:26:07 gabriel-bezerra, ++ 16:26:17 it doesn't show sibilings however 16:26:39 when querying parents 16:26:48 ok 16:27:00 so, can we query siblings as well? 16:27:17 no, not yet 16:27:20 would it be interesting? 16:27:23 ok 16:27:37 but does it show parents and the parents' parents? 16:27:40 would it be a desirable feature? 16:27:56 i don't know, i was just curious 16:28:07 abrito, yes 16:28:13 parent list will be sufficient ...for nova 16:28:42 sajeesh, just the project_id is sufficient? 16:29:12 right .now ...only that is sufficient 16:29:20 sajeesh, great 16:29:28 I mean according to the present design 16:29:56 sajeesh, ok 16:30:51 we can move to the next topic about quotas? 16:31:06 ok 16:31:19 so.. 16:31:29 there is this effort to put together a library or a service to do quota enforcement and management. 16:31:55 that salvatore from neutron started on the mailing list and was discussed on the summit 16:32:11 #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg39958.html 16:32:22 #link https://etherpad.openstack.org/p/kilo-oslo-common-quota-library 16:32:57 it is still in its very start. people are still discussing the architecture, whether it should be a library, an app, some mix, local vs remote enforcement... 16:33:11 ok 16:33:33 I can see that you have worked on hierarchical quotas for nova 16:33:45 yes 16:33:47 there is also some (partial?) implementation of domain quotas 16:34:06 and it would be great if we could reuse that work on the common library/service 16:34:16 it was done by Vinod 16:34:24 it could even be extended to other kinds resourses besides instances 16:34:52 ok 16:35:25 I have extended the present nova quota driver 16:35:37 which is single level 16:36:14 sajeesh, I think that we should try our best to include the hierarchical quotas code in Nova 16:36:20 sure 16:36:33 ASAP :) 16:36:43 raildo,the implementation is over and testing is in the final phase 16:37:01 a few more use cases only need to tested 16:37:23 so, after that, we can help salvatore to send the code to Oslo 16:37:37 or whatever library/module 16:37:38 ok 16:37:42 sajeesh, great and the spec? 16:37:48 gabriel-bezerra, ++ 16:37:54 the spec is still under review 16:38:06 that is the important part 16:38:33 sajeesh, I believe that we have to talk with the Nova folks to approve this spec to Kilo-1 16:38:45 ++1 16:39:02 do you know about schwicke? 16:39:18 he'll be back next week 16:39:22 I believe that it can speed up this process 16:39:23 ok 16:39:29 +1 16:40:36 raildo,what all the changes will be there once shared lib will be used for QM 16:42:08 I mean when compared to the current set up 16:42:17 sajeesh, sorry, I don't understand, do you talk about the quota code? 16:42:25 yes 16:42:29 quota management 16:42:40 ok 16:43:27 from the mails it is not very clear 16:43:33 hum, i believe that we have to talk with salvatore about that 16:43:43 +1 16:44:03 sajeesh: as I said, there is still a lot of discussions about how it should be done 16:44:09 ok 16:44:30 there is a trend to local enforcement and centralized management, maybe on keystone 16:44:42 a bias 16:44:43 ok 16:44:59 the local enforcement might be a library or an agent 16:45:10 ok 16:45:48 can you please tell why two types of enforcements are required 16:46:17 i mean that they are discussing between both alternatives 16:46:22 ok 16:46:27 not that both will be implemented 16:46:40 ok :-) 16:48:05 sajeesh: https://wiki.openstack.org/wiki/Kilo_Release_Schedule 16:48:07 gabriel my big doubt is why keystone is coming in quota management 16:48:24 sajeesh, gabriel-bezerra I think you should get in touch with Salvatore and discover more about the new implementation and what this could affect what already exists. 16:48:32 +1 16:48:35 there is no implementation yet 16:49:05 ok 16:49:06 keystone came as a suggestion to quota management because it is already deployed everywhere 16:49:17 ok 16:49:20 it would be analogous to keystone centralizing policy management 16:49:29 ok 16:49:52 it is not defined yet 16:49:59 it can be another module 16:50:01 ok 16:50:19 ok 16:50:57 so, they have only agreed on the idea and not on the exact implementation 16:51:59 they agree on: there are many policy implementations, a lot of modules have their own implementations, it is bad for user experience 16:52:15 and there is repeated work 16:52:20 duplicated effort 16:52:22 ok 16:53:06 gabriel you had told centralised policy management....any decision on that 16:53:11 we should have a common implementation that all projects can use 16:53:43 ok 16:54:06 any milestone has been set. ? 16:54:20 sajeesh: in that same link raildo sent from morganfainberg there is a summary of the policy discussions 16:54:24 of the summit 16:54:31 ok ..I will read 16:54:44 and they seemed to agree on keystone keeping the policy "files" 16:55:03 ok 16:55:04 instead of they being a local configuration of each module 16:55:30 ok 16:56:38 someone has something more to be discussed? 16:56:39 raildo,will you be contacting Salvatore 16:56:46 sajeesh, great 16:57:10 i'll tell him about your spec on hierarchical quotas 16:57:22 for nova 16:57:22 thanks gabriel 16:57:35 #action sajeesh will talk with salvatore about Quota Management and what this could affect Hierarchical Quotas and Domain Quotas 16:58:08 raildo,doman quotas ? 16:58:30 sajeesh, i believe that gabriel-bezerra can talk about this 16:58:33 hahaha sorry 16:58:37 ok 16:58:38 we have worked on a domain quota driver about a year ago 16:58:58 #action gabriel-bezerra will talk with salvatore about Quota Management and what this could affect Domain Quotas 17:00:10 #endmeeting