18:00:22 <stevemar> #startmeeting keystone 18:00:22 <MaxPC1> 0/ 18:00:24 <openstack> Meeting started Tue Jan 19 18:00:22 2016 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:28 <stevemar> sure has been a crazy week! 18:00:28 <lhcheng> o/ 18:00:29 <openstack> The meeting name has been set to 'keystone' 18:00:32 <ayoung> MaxPC1, ! 18:00:49 <stevemar> thanks everyone in advance for all the review and code they've been pushing :) 18:00:57 * notmorgan is lurking. 18:01:03 <notmorgan> *LURK* 18:01:10 * stevemar insists notmorgan sits in the front 18:01:13 <stevemar> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Main_Agenda 18:01:30 <stevemar> lots of stuff on the agenda today, so expect short discussions 18:01:44 <stevemar> #topic midcycle details 18:02:06 <stevemar> I sent out an email to all the folks coming to the midcycle, i got names from the wiki 18:02:13 <david8hu> \o 18:02:24 * dstanek is likely to get lost if there are over 900 buildings! 18:02:37 <stevemar> no real changes there, just that we'll get "badges" (stickers) the day of and they'll be ready with our names on it 18:02:45 <stevemar> #link https://etherpad.openstack.org/p/keystone-mitaka-midcycle 18:02:57 <bknudson> is there a bus from the hotel? 18:03:10 <stevemar> dstanek: there are only 7 buildings, and and we'll be using the same one every day :) 18:03:18 <stevemar> bknudson: nope, carpool or drive 18:03:28 <topol> bknudson stay at the same hotel as me and I can give you a ride 18:03:32 <stevemar> bknudson: well, not that i know of... 18:03:48 <ayoung> will there be telepresence? I'd like to participate 18:03:51 <bknudson> they probably have uber there 18:03:52 <dstanek> stevemar: i'm in walking distance 18:04:01 <dstanek> bknudson: uber and lyft i believe 18:04:01 <stevemar> dstanek: no bus for you then 18:04:11 <stevemar> ayoung: i can ask about that 18:04:31 <bknudson> at the security meetup they set up google hangout and a couple of people remoted in 18:04:34 <stevemar> #action stevemar to setup video for midcycle 18:04:37 <bknudson> seemed to work ok 18:04:42 <dolphm> telepresence hasn't worked too well for the midcycles that have tried it, unless they go 100% remote, and then you have a whole different set of problems 18:04:56 <samueldmq> anyone staying at Home2 Suites ? :) 18:05:03 * notmorgan hasn't booked hotel yet 18:05:04 <stevemar> samueldmq: i think dstanek is 18:05:06 <notmorgan> will be doing that today 18:05:09 <ayoung> stevemar, something like that would work fine. When we did the summer one, we did the remote demo for dynamic policy that way 18:05:11 <samueldmq> I decided it was better ot just walk 18:05:20 <samueldmq> stevemar: nice! 18:05:23 <dstanek> stevemar: nope. some lonestar place i think 18:05:51 <stevemar> dstanek: i thought home2 was the only one in wakling distance, oh well 18:05:59 <stevemar> ayoung: yep, i'll see what we can do 18:06:09 <stevemar> ayoung: worst case, hangouts like bknudson said 18:06:20 <stevemar> any other q's about the midcycle? 18:06:37 <ayoung> Agenda for topics to discuss? 18:06:41 <ayoung> At midcycle, that is? 18:06:56 <stevemar> ayoung: no agenda yet, but i added topics and timeslots to the etherpad: https://etherpad.openstack.org/p/keystone-mitaka-midcycle 18:07:02 <samueldmq> ayoung: yes it worked :) 18:07:33 <samueldmq> stevemar: are we also supposed to use https://etherpad.openstack.org/p/keystone-mitaka-midcycle-meetup ? 18:07:41 <samueldmq> stevemar: in addition to this one you said ^? 18:07:54 <topol> notmorgan is actually coming??? 18:07:59 <stevemar> samueldmq: i don't know who created that one 18:08:09 <stevemar> samueldmq: just squash the content into https://etherpad.openstack.org/p/keystone-mitaka-midcycle if possible? 18:08:11 <dstanek> we just need to make sure we have enough time to come to a resolution on topics that need it 18:08:16 <stevemar> since one has much more content 18:08:18 <samueldmq> stevemar: me neither, sure! 18:08:45 <stevemar> dstanek: agreed 18:09:11 <stevemar> we can take a vote on topics that need discussion the first morning we get there 18:09:20 <bknudson> some of these are work items and not something we need to discuss 18:09:33 <samueldmq> stevemar: done 18:09:34 <ayoung> You guys are going to get so much done without me there to derail 18:09:38 <dolphm> stevemar: are we supposed to fill in the schedule? 18:09:40 <samueldmq> bknudson: nice, I will add 2 sections 18:10:05 <bknudson> why 2 sections? 18:10:14 <stevemar> dolphm: no, lets fill it in the morning of 18:10:22 <stevemar> dolphm: or i'll make that call 18:10:26 <dolphm> stevemar: "will be populated from topics & todos" ? 18:10:50 <samueldmq> bknudson: list of topics to be discussed vs only worked on 18:10:53 <stevemar> dolphm: yes, it will be 18:11:13 <bknudson> ok... seems like we can put everything in 1 section 18:11:25 <samueldmq> wfm 18:11:25 <bknudson> as in, things people want to do at the midcycle 18:11:36 <stevemar> bknudson: right 18:11:52 <stevemar> can't we can divide that up in the first morning there? 18:12:20 <stevemar> there's discssion, then there's work items folks want to accomplish 18:13:14 <stevemar> fill in topics and things to do, i'll massage it a bit 18:14:23 <notmorgan> topol: yes. but... 18:14:24 <stevemar> seems like a good time for the next topic 18:14:34 <stevemar> #topic API working group liaison 18:14:40 <notmorgan> ayoung: i promise to derail things in your absence 18:14:47 <ayoung> notmorgan, thanks 18:15:08 <stevemar> so dolphm has stepped down as the API working group liaison, anyone want to pick up and run with it? 18:15:18 <stevemar> dolphm: can you mention some of the responsibilities? 18:15:30 <gyee> that defcore work? 18:15:33 <dolphm> sure- 18:15:36 <stevemar> dolphm: or more importantly, time commitment 18:15:38 <notmorgan> gyee: not exactly. 18:16:14 <dstanek> dolphm: yes, what is the time commitment like? 18:16:16 <dolphm> from my perspective, the job is mostly to maintain awareness of, if not participate in, the API Working Group, and to come back to keystone and review API-impacting keystone-specs reviews accordingly, raise awareness of new standards/conventions/etc 18:16:49 <dolphm> dstanek: it's just a shift in code review focus in my book, so... zero ;) 18:17:00 <stevemar> btw, this is open to anyone, not just cores 18:17:14 <bknudson> do they have a weekly meeting to attend? 18:17:15 <gyee> what's the pay like? 18:17:21 <gyee> :) 18:17:32 <dolphm> bknudson: https://wiki.openstack.org/wiki/API_Working_Group 18:17:36 <lbragstad> gyee the occasional coffee/beer at summits 18:17:36 <dstanek> yes, yep 18:17:49 <dolphm> https://wiki.openstack.org/wiki/Meetings/API-WG 18:17:59 <dolphm> but honestly, all the important stuff is in gerrit 18:18:04 <dstanek> don't all jump in at once! i'd be interested 18:18:07 <dolphm> and there's been a tiny bit on the mailing list 18:18:51 <dstanek> i already watch the evening meeting - so it would just mean participating 18:18:53 <stevemar> dstanek, cool with me, i think you're already a liaison for something, but as long as you're sure you can handle it 18:19:24 <stevemar> dstanek: y, you are QA liaison, but above comment still applies 18:19:47 <dstanek> stevemar: yes, i don't mind 18:19:51 <samueldmq> ++ for dstanek, however I'd be able to take it no-core is able to 18:20:01 <samueldmq> dstanek: nice then :) 18:20:06 <stevemar> dstanek: thanks, dude. 18:20:13 <henrynash> ++ to dstanek 18:20:15 <dolphm> #startvote Elect a new API-WG liaison? dstanek 18:20:16 <stevemar> dstanek: i'll let the right folks know 18:20:17 <openstack> Only the meeting chair may start a vote. 18:20:17 <dolphm> #vote dstanek 18:20:19 <dolphm> #endvote 18:20:22 <bknudson> thanks dstanek 18:20:22 <raildo> lol 18:20:23 <stevemar> lol 18:20:24 <dolphm> dstanek: woo, congrats! 18:20:30 <samueldmq> haha 18:20:33 <lbragstad> that was trickery 18:20:39 <stevemar> you guys are gonna love this next topic... 18:20:47 <stevemar> #topic Cross-Project liaison 18:20:47 * dstanek feels like he was just thrown into a fire pit 18:20:58 * dolphm hugs dstanek 18:21:12 <stevemar> this is *new* position 18:21:20 <stevemar> the cross-project liaison 18:21:21 <bknudson> I'm already watching x-project for security, and I also attend because of oslo 18:21:31 <stevemar> responsibilities are here: http://docs.openstack.org/project-team-guide/cross-project.html#cross-project-specification-liaisons 18:21:45 <gyee> sounds like a punching bag position 18:21:45 <bknudson> So I'll volunteer. 18:21:48 <dolphm> #startvote Elect a new cross project liaison? bknudson 18:21:49 <openstack> Only the meeting chair may start a vote. 18:22:05 <stevemar> bknudson: that works for me 18:22:08 <dolphm> #vote bknudson 18:22:09 <dolphm> #endvote 18:22:09 <bknudson> of course I'd be happy to see someone else on it. 18:22:10 <dolphm> woo 18:22:18 <stevemar> bknudson: i'll help out where i can 18:22:26 <stevemar> i also watch the x-project specs 18:22:27 <lbragstad> i see a pattern forming 18:22:45 <topol> bknudson, now thats a nomination I can get behind! 18:22:55 <shaleh> Looks like a sham democracy to me :-) 18:22:56 <bknudson> there are already a couple of x-project specs that keystone should be following 18:23:09 <bknudson> request IDs from the python API 18:23:16 <bknudson> and the service catalog standardization 18:23:16 <samueldmq> stevemar: core-only for this one ? 18:23:23 <dolphm> in all seriousness, cross-project awareness and communication is a growing issue in openstack, and i'd openly encourage & welcome anyone that wants to step up 18:23:27 <ayoung> I don't like the other projects 18:23:39 <shaleh> ayoung: they relly dont like us :-) 18:23:41 <bknudson> and there's some proposed also -- for using the CLI (which we're already done with) 18:23:50 <bknudson> for using openstack CLI 18:23:53 <stevemar> samueldmq: preferred, for the reasons dolphm just said, but please please participate, it's very important 18:23:55 <dolphm> samueldmq: no reason to restrict liaisons to existing -core at all 18:24:07 <dolphm> stevemar: disagree! 18:24:19 <samueldmq> cool, I'll volunteer too 18:24:19 <amakarov> dolphm, maybe there should be more than just a single person for x-project communication? 18:24:30 <bknudson> my vote is for samueldmq then. 18:24:35 <dolphm> liaisons priority is communication-first, not necessarily reviewer-first 18:24:42 <lbragstad> I was just going to ask, does it have to be restricted to one person? 18:24:52 <stevemar> dolphm: i did say *preferred*, no required 18:25:02 <gyee> bknudson, link for the SC standardization patch? 18:25:11 <dstanek> one person needs to be responsible, but i see no reason why others can't get involved 18:25:21 <bknudson> gyee: it's merged already... let me find it! 18:25:30 <dolphm> one of the other functions of liaisons is to have externally-facing project contacts, so there's no harm in having a list of people willing to be contacted 18:25:32 <ayoung> when is the X proj meeting? 18:25:37 <stevemar> gyee: it's here: http://specs.openstack.org/openstack/openstack-specs/ 18:25:48 <stevemar> ayoung: just after this one? or two hours after? 18:25:56 <ayoung> I can take it. 18:25:59 <bknudson> gyee: https://review.openstack.org/#/c/181393/ 18:26:03 <lbragstad> dstanek agreed, as long as the people acting a liaisons stay up on communication with each other 18:26:03 <stevemar> now everyone wants to do it! 18:26:09 <ayoung> I've been pushing X proj specs enough 18:26:26 <samueldmq> lbragstad: ++ 18:26:37 <ayoung> I said "can" not "want to" 18:26:42 <ayoung> will do if needed 18:26:52 <dolphm> there are also working group meetups at the summits - while not strictly required, i'd sincerely hope the liaison can/will attend 18:26:53 <stevemar> ayoung: let's let samueldmq have it :) 18:27:03 <bknudson> samueldmq sounds like he wants to. 18:27:16 <samueldmq> I'd be glad, will do my best :) 18:27:20 <stevemar> done 18:27:27 <stevemar> samueldmq you are the new x-project dude 18:27:29 <gyee> #vote for samueldmq 18:27:33 <bknudson> thanks samueldmq! 18:27:47 <dstanek> samueldmq! 18:27:48 <amakarov> samueldmq, congrats! 18:27:48 <topol> thanks samueldmq 18:27:50 <dolphm> #vote samueldmq 18:27:51 <ayoung> works for me 18:27:59 <topol> speech speech speech 18:28:01 <samueldmq> thanks hehe 18:28:03 <stevemar> hehe 18:28:17 <stevemar> #topic keystone user survey 18:28:24 <samueldmq> bknudson: might need to get a bit more details with you after meeting 18:28:33 <bknudson> samueldmq: no problem 18:28:49 <stevemar> so, i was asked if we want to provide new questions about keystone for the user survey 18:28:56 <stevemar> anyone can add questions here: https://etherpad.openstack.org/p/keystone-mitaka-user-survey 18:29:26 <stevemar> the previous keystone related questions for the user survey i saw were pretty bad 18:29:58 <stevemar> they didn't discriminate between the resources and backends, it was just "do you use ldap, y/n?" 18:30:32 <stevemar> if you have a few minutes, add a question, i figured if everyone adds one, then that's good enough 18:30:55 <stevemar> otherwise, i'll add a bunch on my own 18:31:41 <gyee> stevemar, when do you need them by? 18:32:24 <stevemar> gyee: Due Jan 21, 2016 18:32:48 <stevemar> i can polish the question, if folks want to write it in short form 18:33:08 <stevemar> here's an example question from last year: Which OpenStack Identity Service (Keystone) drivers are in use? 18:33:22 <stevemar> the options are LDAP/SQL/AD/PAM/Templated/KVS .... 18:33:40 <stevemar> https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf 18:33:58 <stevemar> that's pretty much our own insight into users and operators that is metric based ... 18:34:01 <stevemar> and kinda sad 18:34:34 <stevemar> so, if we're actually serious about operator feedback, then take a few minutes to add a question, i think it'll be worthwhile 18:34:54 <gyee> #1 Do you use Keystone? Yes/No 18:35:31 <shaleh> gyee: actually valid, right? Could be a Swift only shop 18:35:32 <stevemar> gyee: i think that's already asked :) 18:35:53 <stevemar> all this silence isn't good, i think i lost folks :( 18:36:05 <raildo> stevemar: all of us can suggest some questions, right? 18:36:11 <stevemar> raildo: for sure 18:36:11 <htruta> let's ask if they use v2. If so, why? 18:36:16 <stevemar> htruta: yep 18:36:22 <notmorgan> there is also more nova deployments than keystone deployments 18:36:23 <samueldmq> I'm here o/ 18:36:27 <notmorgan> as an interssting datapoint 18:36:32 <notmorgan> as of the last survey 18:36:41 <samueldmq> notmorgan: ++ 18:36:45 <stevemar> notmorgan: could just be people filling out data incorrectly 18:36:48 <topol> o/ ack 18:36:54 <samueldmq> #link http://www.openstack.org/software/project-navigator 18:36:54 <ayoung> meh...people are not interested in Keystone. Either it works for them or they work around it 18:36:59 <samueldmq> keystone has 96% adoption 18:37:12 <raildo> ayoung: :( 18:37:29 <ayoung> raildo, Implied roles is the first step to fix that 18:37:33 <amakarov> samueldmq, how this can be measured? 18:37:33 <stevemar> help out if you can 18:37:37 <shaleh> Identity is not sexy or interesting. It is a necessary step for them. That is all. 18:37:39 <topol> ayoung, the selfhating core 18:37:48 <ayoung> topol, I don't hate myself 18:37:48 <stevemar> topol: ++ 18:37:49 <ayoung> I love me 18:37:57 <ayoung> I am just frustrated by Keystone 18:38:04 <samueldmq> amakarov: survey 18:38:05 <bknudson> let's make keystone something we can all love 18:38:11 <gyee> ++ 18:38:24 <stevemar> ayoung: "how can i make keystone something we can all love?" 18:38:31 <stevemar> anywho 18:38:32 <ayoung> stevemar, no 18:38:46 <stevemar> now that fun topic is over.. 18:38:49 <stevemar> #topic Feature proposal freeze is today 18:38:50 <amakarov> stevemar, a title for a new book? 18:38:54 <bknudson> let's just have ayoung write all the code 18:38:54 <dstanek> stevemar: you can't please everyone so you shouldn't even try 18:38:55 <stevemar> amakarov: lol 18:39:10 <stevemar> No patch up for review for a feature (spec or blueprint)? The feature will now target N. 18:39:22 <ayoung> bknudson, just approve my patches without all the nitpicking would be a good start 18:39:25 <stevemar> i don't think we have any folks in danger of that... ? 18:39:30 * ayoung done whining 18:39:41 <breton> stevemar: if it's not merged or not proposed? 18:39:45 <stevemar> #link http://docs.openstack.org/releases/schedules/mitaka.html#keystone 18:39:54 <stevemar> breton: proposed 18:40:13 <stevemar> breton: if there was a feature, and there is NO code for it (as of today), it's being pushed to N 18:40:40 <henrynash> stevemar: quite right to 18:40:54 <stevemar> we're also approaching mitaka-2 deadline 18:41:05 <stevemar> so anything that isn't GATING today, will be pushed to mitaka-3 18:41:08 <bknudson> can we propose specs to N? 18:41:21 <stevemar> bknudson: sure 18:41:51 <stevemar> the mitaka-2 to mitaka-3 change isn't a big deal. you now have a few more works to get things ironed out 18:41:57 <stevemar> weeks* 18:42:23 <stevemar> i already moved shadow users and domain specific roles (and a few others) to mitaka-3: https://launchpad.net/keystone/+milestone/mitaka-3 18:42:36 <stevemar> for a snapshot of what's going into mitaka-2, here: https://launchpad.net/keystone/+milestone/mitaka-2 18:42:57 <gyee> implied roles made it! 18:43:19 <stevemar> ayoung tjcocozz samueldmq, you guys are on the border, if you get your patches +A'ed today, then y'all have made it 18:43:29 <stevemar> gyee: there are 2 patches for implied roles :) 18:43:48 <gyee> thought they are both A+ed, lemme check 18:43:56 <ayoung> then approve the damn thing and file bugs 18:44:08 <samueldmq> stevemar: + one I will on to eal with circular references :) nits may be fixed later 18:44:21 <samueldmq> ayoung: lol 18:44:22 <stevemar> yep 18:44:33 <ayoung> seriosusly, it is about 50 lines fo code...and 300 of unit tests 18:44:46 <stevemar> i thought there'd be more discussion here 18:44:53 <stevemar> everyone needs coffee 18:44:56 <htruta> stevemar: are we makring bps for mitaka-3 today? 18:44:59 <ayoung> close to 400 of tests 18:45:04 <htruta> marking* 18:45:12 <stevemar> htruta: i already marked most 18:45:17 <samueldmq> ayoung: anything else besides https://review.openstack.org/#/c/242614 18:45:19 <samueldmq> ? 18:45:34 <stevemar> htruta: if they are not in by today, then they will become mitaka-3 as well 18:45:40 <ayoung> samueldmq, well, there is all of henrynash 's patches that depend on it 18:45:52 <samueldmq> ayoung: but that's domain roles 18:45:54 <henrynash> stevemar: the projects acting as domains part of reseller doesn’t appear in either the m2 or m3 lsits (but is tagged for mitaka)…. 18:45:56 <samueldmq> ayoung: which is m3 18:45:56 <gyee> ayoung, that's the last patch right? https://review.openstack.org/#/c/264260/ 18:46:02 <stevemar> breton: btw, you owe me a release not for truncated stuff 18:46:14 <stevemar> henrynash: link me? 18:46:15 <ayoung> gyee, that is driver, then the API is https://review.openstack.org/#/c/242614 18:46:15 <htruta> stevemar: nice 18:46:16 <breton> stevemar: will do 18:46:20 <ayoung> useless without API going in 18:46:35 <gyee> ayoung, why its a different topic? 18:46:35 <stevemar> henrynash: it'll target mitaka-3 likely 18:46:41 <ayoung> gyee, NPI 18:46:44 <samueldmq> gyee: are you confused with new gui ? (I am ) 18:46:52 <henrynash> stevemar: https://blueprints.launchpad.net/keystone/+spec/reseller 18:46:57 <gyee> samueldmq, I was going by the "topic" 18:47:06 <henrynash> steevmar: yes m3 18:47:06 <gyee> and I only see 3 patches for implied roles 18:47:11 <stevemar> henrynash: ok 18:47:12 <ayoung> gyee, I blame henrynash as he rebased his changes on mine, and I think he grabbed the topic 18:47:22 <stevemar> ayoung: probably 18:47:24 <henrynash> ayoung: moi? 18:47:38 <stevemar> next topic! 18:47:41 <stevemar> #topic Removing Role LDAP backend 18:47:53 <stevemar> notmorgan: you wanna take this one? i'm tired of typing :P 18:48:03 <bknudson> Role LDAP backend seems useles 18:48:05 <bknudson> useless 18:48:28 <gyee> ya think? 18:48:40 <notmorgan> yes 18:48:43 <notmorgan> it is useless 18:48:46 <stevemar> so, we decided back in K to remove Assignment and Resource LDAP backends, which we have been emiting deprecations for We are removing the Assignment and Resource LDAP backends here: https://review.openstack.org/#/c/231872 18:48:47 <notmorgan> we should kill it 18:49:01 * topol I'm still waiting for gyee to deliver the one and only best schema for it 18:49:05 <notmorgan> basically what stevemar just said. 18:49:11 <ayoung> It can go away 18:49:18 <stevemar> but when we split assignment into role and assignment, we messed up and didn't emit deprecations for role LDAP 18:49:23 <dstanek> ++ to killing it 18:49:33 <stevemar> there's a seperate patch to kill it: https://review.openstack.org/#/c/269385/ 18:49:42 <gyee> topol, its posixGroup :-) 18:49:45 <stevemar> i think it's broken if you don't have assignment in there anyway 18:49:47 <ayoung> henrynash, TBH, I would be happier with DSRs under the Implied role topic, to make clear to people that it is one continuous path 18:49:51 <bknudson> maybe we can just say it's implied in the other deprecations 18:49:59 <stevemar> bknudson: i think so 18:50:12 <stevemar> okay, it seems unanimous, we can kill it 18:50:12 <henrynash> stevemar, bknudson: agreed 18:50:28 <stevemar> it's in the release note 18:50:34 <gyee> killing it softly 18:50:42 <stevemar> gyee: ripping it out isn't soft 18:50:47 <bknudson> we'll see if anybody notices 18:50:48 <stevemar> lets give lhcheng and raildo some time 18:50:52 <lbragstad> notmorgan dstanek lets remove it, consolidate the tests and simplify the code 18:50:52 <stevemar> #topic Adding parent_id in the token 18:50:53 <notmorgan> and it was also referenced in the email 18:50:54 <ayoung> bknudson, that is correct. It is implied; roles were part of assignemtn when we said we were goimng to deprecate assignemnt LDAP backend 18:50:59 <ayoung> stevemar, -2 18:51:01 <notmorgan> that was sent >1yr ago 18:51:05 <ayoung> no parent in token 18:51:26 <stevemar> ayoung: i'll bite, why? 18:51:28 <henrynash> ayoung: I’m not fussed either way….although if we change it I’ll probably mess it up with git again :-) 18:51:29 <raildo> so, we found a bug on cinder, and we have the same issue on nova 18:51:32 <raildo> #link https://bugs.launchpad.net/cinder/+bug/1531502 18:51:33 <openstack> Launchpad bug 1531502 in Cinder "Child project's default quota not enforced" [High,New] - Assigned to Ryan McNair (rdmcnair) 18:51:36 <ayoung> stevemar, it is neither necessary nor sufficient 18:51:47 <ayoung> you need quota, just knowing the parent is not sufficient 18:52:11 <ayoung> if there is a tree, you need to know the whole tree to calc quota 18:52:25 <ayoung> so, let's say in keystone I make the following: 18:52:38 <ayoung> Domain1->p1->p2->p3->4 18:52:39 <gyee> ayoung, why the whole tree if you only set the quota on the domain? 18:52:41 <bknudson> from memory, the projects were going to have a cache of the project hierarchy that they could consult 18:52:53 <lhcheng> cinder/nova needs to make a call to GET project to fetch the parent_id for the quota calculation. however, our policy rule is too restrictive for the GET project. 18:52:56 <ayoung> and I want to check quota on p4, which is inherited from p1 18:53:03 <henrynash> stevemar, ayoung: so to bit more…is it that without parent in the token someone can’t build the tree, or that they want to be “efficient” and not have to call keystone build a tree each time? 18:53:07 <ayoung> they need to know more than just p3->p4 18:53:11 <raildo> ayoung: for now, you can just change quota for the immediate child, so the parent_id will be enough for now 18:53:32 <ayoung> henrynash, right, you can't build enouigh of the tree to matter 18:53:50 <amakarov> bknudson, or they should contain this information in the model: https://review.openstack.org/#/c/251445/ 18:53:54 <ayoung> raildo, so...set quota should be using a parent scoped token. 18:53:57 <samueldmq> stevemar: not sure I understood it well, but I had a patch for deprecating role api and I got a -1 hence that wasn't fair to deployers to remove it in +1 ? 18:54:00 <ayoung> not child 18:54:10 <ayoung> use my example above 18:54:24 <ayoung> say I have a role on p1 that lets me change quota 18:54:26 <lhcheng> ayoung: the quota check is only applied to its direct parent, so only need to know p4-> p3 18:54:38 <raildo> ayoung: and they use aparent scoped token for set, but a member user can't get quota for their project... 18:54:42 <ayoung> lhcheng, circular reasoning 18:54:43 <raildo> ayoung: that is the problem 18:54:52 <ayoung> the check is on applied because they wrote this request this way 18:55:00 <ayoung> it is neither necessary nor sufficient 18:55:37 <gyee> raildo, you want to put up a POC patch to show ayoung it is sufficient? 18:55:45 <ayoung> If I get a token scoped to P3 in order to "pull down" quota 18:55:59 <ayoung> gyee, it is a recursive problem 18:56:10 <gyee> otherwise, we are just arguing abstract 18:56:13 <raildo> gyee: sure, I can do that, and we can discuss this next week 18:56:31 <ayoung> if I call set quota on P4, I need a token scoped to P3, and the service needs to query the tree from p3 up to Domain1 18:56:49 <mc_nair> so the particular issue is also with enforcement of default child quotas. User creates a volume, we know to use the default quota cause none is set. All we need to know is should defaults be child defaults (all 0s) or not. We don't have any way to grab the project from keystone because volume create isn't an admin operation. 18:57:13 <lbragstad> 3 minutes left 18:57:33 <bknudson> implement a way to get the project from keystone. 18:57:39 <bknudson> we make changes to keystone all the time. 18:57:55 <ayoung> bknudson, I thought we had a query to get the whole tree? 18:58:03 <gyee> we do 18:58:07 <bknudson> yes, we do have a query to get the whole tree 18:58:10 <raildo> bknudson: we already implemented, the problem is that to get the project, you must need to be admin 18:58:10 <ayoung> then they should use that 18:58:13 <mc_nair> bknudson: that's another option, to let get_project be a non-admin command (can get your current project). 18:58:17 <bknudson> so be admin then 18:58:18 <ayoung> raildo, implied roles 18:58:26 <stevemar> or change the policy 18:58:30 <ayoung> don't try to fix things by working around RBAC 18:58:31 <lhcheng> isn't that a privileged query? - GET project 18:58:32 <bknudson> what's stopping someone from being admin? 18:58:34 <mc_nair> but then we need to hit that API on any volume create, nova create, etc 18:58:45 <ayoung> mc_nair, yes you do 18:58:46 <ayoung> and? 18:58:51 <dolphm> lhcheng: why? 18:59:20 <dolphm> it's just a read, and the IDs aren't guessable 18:59:20 <stevemar> we're at time folks 18:59:22 <ayoung> anything that does a quota check, where the quota is not yet set for the project. You need to know the tree. But the trees are immutable, so cache them 18:59:32 <lhcheng> dolphm: right now it is privileged, maybe it should be less restrictive 18:59:36 <stevemar> lets leave and give the room to infra 18:59:40 <stevemar> continue in -keystone 18:59:46 <stevemar> #endmeeting