16:02:51 <schwicke> #startmeeting hierarchical_multitenancy
16:02:52 <openstack> Meeting started Fri Jul 25 16:02:51 2014 UTC and is due to finish in 60 minutes.  The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:57 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
16:03:10 <schwicke> couple of things to be discussed today
16:03:32 <sajeesh> schwicke ....default quota ! !
16:03:53 <schwicke> I'd like to start with a short overview where we are
16:03:59 <sajeesh> ok
16:04:02 <Nirbhay_> ok
16:04:09 <schwicke> #topic status
16:04:29 <schwicke> I think the keystone specs are in for Juno
16:04:37 <schwicke> that's great !
16:04:45 <sajeesh> great
16:05:04 <raildo> Regarding the approval of the spec. Dolph told me that we don't need to worry about the deadline but he would like a devstack installation with the code running.
16:05:21 <raildo> So I created a VM in my cloud and I'll provide a link for testing.
16:05:25 <schwicke> for the nova parts we were too late, and with two minuses there was no way to get an exception
16:05:30 <raildo> and i created a wiki about the hierarchical multitenancy API. https://wiki.openstack.org/wiki/HierarchicalMultitenancy_API#Hierarchical_Multitenancy_API
16:05:44 <schwicke> great!
16:06:16 <schwicke> the nova folks are discussing if the current policy is optimal from what I have seen.
16:06:17 <sajeesh> good
16:06:22 <Nirbhay_> nice
16:06:54 <schwicke> we had quite a bit of discussions inside the team in the past couple of days
16:07:20 <schwicke> and IMO we should rewrite the nova spec from scratch. The old one is in "abandoned state"
16:07:45 <sajeesh> schwicke ,I have started it
16:08:17 <schwicke> ok. I would like to have an internal review first before we publish it
16:08:29 <raildo> sounds good to me
16:08:34 <schwicke> We also need to add the dependencies which were missing in the previous specs
16:08:41 <sajeesh> ok...will send you in a couple of days
16:08:51 <schwicke> the keystone stuff is a prerequisit
16:09:00 <sajeesh> yes
16:09:20 <schwicke> possibly also the blue prints about nova keystone V2 -> V3 which as far as I know didn't make it either
16:09:23 <Nirbhay_> sajeesh , make it as simple as possible...
16:09:29 <sajeesh> ok
16:09:42 <Nirbhay_> ok
16:10:36 <schwicke> #agreed hierarchical quota specs to be rewritten from scratch
16:10:54 <schwicke> #agreed do a thorough internal review before publishing
16:11:10 <schwicke> # agreed add dependencies
16:11:46 <schwicke> change of topic: there is one remaining thing to be decided on
16:11:54 <schwicke> #topic default quota
16:12:18 <schwicke> short summary of the offline discussions:
16:12:20 <schwicke> non zero default quota can result in a race condition
16:12:37 <schwicke> and wrong accounting
16:12:44 <raildo> today, we have this values, ok? https://github.com/openstack/nova/blob/master/nova/quota.py#L34
16:13:18 <schwicke> yep
16:13:25 <schwicke> I'd like to question that actually :)
16:13:34 <schwicke> I don't think it makes sense at all.
16:13:52 <schwicke> correct me if I'm wrong but projects are created inside keystone only
16:14:00 <raildo> yes
16:14:07 <schwicke> and nova does not know about those projects a priori
16:14:30 <schwicke> So you could have zero resources in nova and tons of quotas allocated in keystone
16:14:39 <schwicke> resulting in very disappointed users.
16:14:48 <sajeesh> raildo,will nova come to know if a project is newly created or destroyed
16:14:48 <sajeesh> earlier,you had talked about synchronizing keystone with other services
16:15:57 <schwicke> if it works as I think it works then the initial values should be neutral (eg 0) and they would have to be changed with an API call to nova
16:16:12 <schwicke> which in turn would solve our little race condition scenario.
16:16:52 <raildo> At other times I have discussed about the keystone notify services about these changes, but it seems to be complicated.
16:16:53 <raildo> https://blueprints.launchpad.net/horizon/+spec/tenant-deletion
16:17:02 <raildo> #link https://blueprints.launchpad.net/horizon/+spec/realtime-communication
16:17:04 <sajeesh> ok
16:17:32 <Nirbhay_> ok
16:17:44 <sajeesh> raildo ,you mean currently there is no such notification ?
16:18:33 <raildo> not real-time, so I have no way to tell to Nova that I created a new project.
16:18:52 <sajeesh> what about deletion ?
16:19:00 <sajeesh> deleting a project ?
16:19:51 <schwicke> I think deleting a project is not an issue as long as a project cannot be deleted unless it is empty/unused
16:20:09 <raildo> I would have to analyze better the code, but I know that notifications are not in real time.
16:20:20 <schwicke> I don't get why there are non-zero default quotas in Nova right now :)
16:20:30 <schwicke> ok
16:20:57 <raildo> schwicke: +1
16:21:00 <schwicke> Maybe we should raise that on the openstack-dev list
16:21:24 <raildo> It will be a good discussion
16:21:28 <schwicke> if the default quotas are zero and have to be changed via a nova api call we have no problem
16:21:32 <schwicke> :)
16:21:40 <schwicke> raildo: +1
16:22:23 <schwicke> ok, so ...
16:22:49 <schwicke> #action ask the non-zero quota issue on the dev list
16:22:58 <Nirbhay_> schwicke, deletion of project will also matter even if it is empty
16:23:07 <schwicke> why ?
16:23:31 <Nirbhay_> as project might be empty but it will have some quota assigned to it..if it is deleted parent should come to know to update its allocated quota
16:23:42 <VINOD_> hi...sorry for very late
16:23:57 <Nirbhay_> no instances does  not mean no quota allocated to it..
16:23:59 <schwicke> Nirbhay: you are right.
16:24:17 <raildo> hi VINOD_
16:24:25 <VINOD_> raido: hi
16:24:29 <schwicke> however, if there are notifications even if they come in delayed I don't think there is an issue
16:24:42 <schwicke> VINOD_: Hi! Welcome
16:25:28 <VINOD_> schwicke: hi
16:25:42 <schwicke> people wil lhave to wait a bit before those quotas are released again.
16:25:51 <raildo> Nova is notified somehow, I just do not know exactly how this is done.
16:25:53 <schwicke> However, numbers should stay consistent.
16:26:15 <schwicke> raildo: maybe we should find out how this works
16:27:03 <raildo> I will test this function and i respond by email.
16:27:11 <schwicke> ok great!
16:27:22 <schwicke> raildo: thanks a lot!
16:27:54 <schwicke> #action raildo will test how nova is notified in the case of the deletion of a project
16:28:12 <raildo> schwicke: no problem :)
16:28:25 <Nirbhay_> does any one know, how  in present openstack deployments nova assigns default quota to project
16:28:41 <VINOD_> Nirbhay: i had sent a mail today about this.
16:28:52 <Nirbhay_> as now also projects are created in keystone current default quota lies with noca
16:28:55 <Nirbhay_> **nova
16:29:13 <VINOD_> Nirbhay: Nova has a default quota values hard coded in "quota.py"....
16:29:25 <Nirbhay_> i will go through it
16:29:32 <VINOD_> Nirbhay: If you don't set the quota for a project, these default value applies and is not stored in the database
16:30:04 <schwicke> Raildo had sent the link earlier in the meeting
16:30:14 <sajeesh> sorry ...my connection got interrupted
16:30:23 <Nirbhay_> but project is created in keystone, then they are link, or when nova actually create a row for that project in its quota table
16:30:24 <schwicke> (for those joining in late :) What time is it in India ? )
16:30:24 <VINOD_> yes, #link https://github.com/openstack/nova/blob/master/nova/quota.py
16:30:36 <VINOD_> It is 10 PM
16:30:38 <sajeesh> 10'o clock
16:31:03 <schwicke> great that you connect anyway !
16:31:06 <schwicke> +1
16:31:29 <VINOD_> Nirbhay: Nova creates an entry in nova only for those attribues for which quota is set..i mean if somebody set the value for "instances" attribues
16:31:49 <VINOD_> Nirbhay: this values will be saved in the database and rest will be taken from the default values present in quota.py
16:32:05 <Nirbhay_> ok
16:32:10 <Nirbhay_> now clear to me..
16:32:27 <schwicke> so I suggest we wiat for Raildos mail and then, depending on the outcome, ask the question about default quotas on the dev list
16:32:35 <sajeesh> ok
16:32:52 <VINOD_> schwicke: ok
16:32:53 <Nirbhay_> ok
16:32:56 <raildo> ok
16:33:28 <sajeesh> shwicke,what about getting immediate child projects from keystone in realtime ? Shall we discuss that ?
16:33:30 <schwicke> #agreed we wait for Raildos mail  and then, depending on the outcome, ask the question about default quotas on the dev list
16:33:53 <schwicke> sajeesh: we have this info in the keystone token.
16:34:16 <raildo> schwicke: +1
16:34:18 <sajeesh> but I think the validity of the token is one hour
16:34:24 <schwicke> sajeesh: the only issue is the race condition due to non-zero default quota
16:34:50 <schwicke> sajeesh: which goes if we can convince the community that the inital values should be zero
16:35:07 <sajeesh> ok
16:35:11 <VINOD_> sajeesh: If we go with storing the "allocated" value, we don't need to worry about child project names in the token
16:35:36 <sajeesh> vinod: that is what I am talking about
16:35:39 <VINOD_> sajeesh: +1 (the only issue i could see the default values)
16:36:39 <Nirbhay_> sajeesh, you will need child list to cross check while handling requests
16:36:55 <Nirbhay_> even if u store allocated value
16:37:01 <VINOD_> +1
16:37:15 <sajeesh> schwicke,whether it is finalized to store the allocated value in nova\
16:37:24 <schwicke> which you have in the token
16:37:56 <sajeesh> token ? allocated value ?
16:38:02 <Nirbhay_> yes token should have child list + allocated value should be stored inDB
16:38:08 <VINOD_> +1
16:38:43 <schwicke> according to the specs currently the token has the full tree information below the project to which the token is scoped
16:38:44 <VINOD_> It sounds good to me as child list will be used to cross check for handling requests and allocated value stored in the db is used to calculate free quota
16:39:28 <sajeesh> I have to check the latest spec
16:39:39 <Nirbhay_> schwicke, full tree info is not there in token, but can be requested sepratly via api call
16:39:42 <VINOD_> with this, i think we don't need to worry if a new child project is created by other admin (and so not present in my earlier created token)
16:40:04 <raildo> talking about the spec... I uploaded today a new version, if you can review, I appreciate it :) https://review.openstack.org/#/c/101017/
16:40:31 <Nirbhay_> token only has child list, but Get /v3/projects/A will give u full tree below A
16:40:33 <sajeesh> raildo, sure
16:40:35 <schwicke> #action review new spec  https://review.openstack.org/#/c/101017/
16:40:56 <VINOD_> raildo: i will certainly go through it and get back to you for any doubts
16:41:21 <VINOD_> sajeesh: Do you need any help in creating the new blue print for quota?
16:41:40 <sajeesh> vinod ,thanks ...I will let you know
16:41:54 <sajeesh> if I am having any doubts
16:42:11 <raildo> VINOD_: and I will strive to answer them doubts
16:42:24 <VINOD_> raildo: thanks
16:42:25 <schwicke> sajeesh: please first circulate interally so that what we publish at the end is already in a good shape.
16:42:35 <VINOD_> +1
16:42:37 <sajeesh> schwicke ,sure
16:42:48 <schwicke> +1
16:42:53 <Nirbhay_> +1
16:43:10 <VINOD_> sajeesh: i guess we need to do this as fast as possible...to meet any little scope of getting accepted this for Juno
16:43:28 <Nirbhay_> schwicke, it is the same we discussed in morning
16:43:38 <schwicke> ok
16:43:51 <schwicke> anything else on this ?
16:43:53 <schwicke> If not I
16:44:05 <schwicke> I'd like to change topic
16:44:06 <VINOD_> schwicke: nothing more from my side
16:44:22 <schwicke> #topic domains and users
16:44:50 <schwicke> reading through the latest comments of raidos specs I got a bit worried about the possible complexity
16:45:43 <schwicke> I understand that users are organized in domains which are not hierarchical, and we said that we'll ignore them in nova
16:46:02 <schwicke> meaning that we don't assign quotas to domains which is fine
16:46:09 <Nirbhay_> yes
16:46:38 <raildo> There was a great discussion on this topic at Keystone and in my team, but we come to this conclusion: "The user management is made through domains. If a user needs to add new users, he needs the ability to create a new domain and to specify the IdP used for that domain. This managemente is well covered by the federation use cases."
16:46:39 <schwicke> do you see any issues to allow a project admin to create a new domain with different users and give them access to his sub-projects ?
16:46:52 <sajeesh> testing
16:47:34 <sajeesh> ping
16:47:34 <sajeesh> ping
16:47:48 <raildo> pong
16:48:32 <schwicke> pong
16:48:58 <raildo> now, i don't see any problem
16:49:20 <schwicke> raildo: at a second glance I think it is fine for our use cases as well
16:49:35 <schwicke> might become a bit complex though.
16:49:49 <schwicke> ok, so no problem with that
16:49:59 <VINOD_> schwicke: IMO, domains can be used as containers for users.....project can be kept as hierachical....
16:49:59 <schwicke> last topic: my failure to move the meeting ...
16:50:26 <schwicke> really sorry about that but it turns out not to be easy.
16:50:55 <schwicke> we have maybe a chance if we move to a different channel.
16:51:07 <sajeesh> right
16:51:22 <Nirbhay_> yes
16:51:24 <VINOD_> schwicke: but then we have to advertise somewhere for people about this new channel
16:51:58 <schwicke> I meant one of the other official channels
16:52:08 <VINOD_> schwicke: ok
16:52:29 <schwicke> will resume on this early next week with a proposal via e-mail. OK
16:52:39 <sajeesh> ok
16:52:44 <schwicke> (that OK was meant to be a question) :)
16:52:46 <raildo> ok
16:52:48 <Nirbhay_> very few meeting are there on other channels
16:52:50 <Nirbhay_> ok
16:52:57 <sajeesh> :-)
16:53:38 <VINOD_> +1
16:54:29 <schwicke> #agreed send another proposal for moving the slot via e-mail early next week
16:54:44 <VINOD_> raildo: one small doubt. I was reading the message before i joined the meeting. It was mentioned, that the keystone blue print is accepted. but i could see no reviewers giving +1 yet. Do we have any chance for our blueprints to be accepted in Juno
16:54:59 <schwicke> #action schwicke to come up with a new meeting slot proposal via e-mail
16:55:48 <schwicke> vinod_: the nova blue print is abandoned
16:56:00 <VINOD_> schwicke: yes, i had seen that
16:56:08 <raildo> VINOD_:  what BP are you talking about? hierarchical multi-tenancy?
16:56:22 <VINOD_> raildo: #link https://review.openstack.org/#/c/101017/
16:57:20 <schwicke> vinod_ : that's on track
16:57:36 <VINOD_> schwicke: ok
16:57:54 <raildo> VINOD_:  According to what I talked with dolph and morgan, I intend to send the code in Juno. the code is approximately 80% done.
16:58:16 <VINOD_> raildo: great..thanks
16:58:18 <morganfainberg> raildo, VINOD_, it is not unreasonable to get the code in during J3
16:58:41 <morganfainberg> raildo, VINOD_, just need to get the rest of the spec (it's not too far off) agreed on and the code reviews started
16:59:18 <VINOD_> sajeesh: So, then we need to be hurry up in preparing the blueprint with the new discussed features on quota as fast as possible
16:59:29 <VINOD_> morganfainberg: thanks
16:59:38 <sajeesh> vinod it will be ready within two days
16:59:48 <VINOD_> sajeesh: thanks
17:00:02 <sajeesh> but before publishing we have to do an internal review
17:00:03 <schwicke> meeting time is over
17:00:12 <raildo> ok
17:00:15 <VINOD_> thanks to all
17:00:28 <Nirbhay_> good bye to all
17:00:32 <schwicke> #endmeeting