18:01:36 <dolphm> #startmeeting keystone 18:01:37 <openstack> Meeting started Tue Feb 18 18:01:36 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:40 <openstack> The meeting name has been set to 'keystone' 18:01:47 <dolphm> #topic Reminder: Icehouse feature proposal freeze TODAY (features must be in code review TODAY) 18:02:08 <bknudson> so new reviews for features get -2? 18:02:12 <dolphm> we look to be in good shape for that goal ^ 18:02:29 <dolphm> so, new *feature* implementations proposed after today will be -2'd until we open for juno 18:02:33 <stevemar> bknudson, yup 18:02:34 <gyee> \o 18:02:50 <nkinder> o/ 18:02:51 <dolphm> which is likely 3-4 weeks from today, IIRC (it's not a hard date, though) 18:03:00 <dolphm> #link https://launchpad.net/keystone/+milestone/icehouse-3 18:03:01 <morganfainberg> dolphm, thats once RC is cut, right? 18:03:04 <marekd> dolphm: juno-1 ? 18:03:28 <dolphm> morganfainberg: yes, RC1 is cut and we re-open for juno-1 on the same day 18:03:31 <stevemar> morganfainberg, yes, once RC1 is cut, thats when juno-1 starts (roughly...) 18:03:40 <topol> o/ 18:03:43 <fabiog> o/ 18:03:44 <dolphm> re-open master, specifically 18:04:05 <joesavak> o/ 18:04:05 <stevemar> info: https://wiki.openstack.org/wiki/Icehouse_Release_Schedule 18:04:12 <stevemar> #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule 18:04:13 <dolphm> we're in pretty good shape for BP's, but we have several bugs that don't have assignees yet 18:04:27 <dolphm> #link https://bugs.launchpad.net/bugs/1276244 18:04:33 <ayoung> bugs can go in after feature freeze, just depends on scope of the solution 18:04:34 <dolphm> #link https://bugs.launchpad.net/bugs/1279849 18:04:41 <dolphm> #link https://bugs.launchpad.net/bugs/1275615 18:04:53 <dolphm> they at least need to be investigated before i3 18:05:08 <dolphm> ayoung: right, but we need to know who's able to work on what ASAP 18:05:11 <ayoung> IE compressed tokens will be OK iff the solution is completely within keystone client and causes no regression. Probably though that will wait. 18:05:19 <dolphm> ayoung: and get an idea for what's going to be an RC-blocker or not ASAP 18:05:41 <dolphm> ayoung: i'd like to keep trying for that on the side, prior to i3 18:05:44 <dstanek> i just took the password one since that is basically what i'm working on now 18:05:59 <ayoung> dolphm, yep, think it is do-able, just going to finish revocation events first 18:06:04 <dstanek> that's 1279849 for those of you playing from home 18:06:21 <henrynash> dolphm: I'll take he v2 tenant one 18:06:36 <dolphm> dstanek: we also have a related security vulnerability that was reported recently - remind me to link you to that after the meeting 18:06:37 <henrynash> https://bugs.launchpad.net/keystone/+bug/1276244 18:06:49 <dstanek> dolphm: ok 18:06:50 <dolphm> henrynash: thanks! assign it to yourself please 18:07:12 <morganfainberg> i'll poke at the ipv6 thing 18:07:24 <morganfainberg> or dual stacked, or ... whatever that actually is 18:07:33 <ayoung> IPv6...nice 18:07:42 <dolphm> morganfainberg: bknudson: i figured one of you might jump on that :) 18:07:49 <morganfainberg> yeah just grabbed it 18:08:00 <dolphm> morganfainberg: should cram ipv6 into the bug title if possible 18:08:02 <ayoung> morganfainberg, keep it low priority. very few people wilk lcry if that doesn't make Icehouse 18:08:11 <morganfainberg> i'll bounce anything i run across against bknudson 18:08:17 <morganfainberg> ayoung, it's med, leaving it as such. 18:08:30 <dolphm> ayoung: ++ it's a weird hole in ipv6 support though 18:08:48 <dolphm> so that's everything assigned then 18:08:58 <ayoung> Oh, don't get me wrong...I think IPv6 is critical. Just not certain if we will have it completely even with this fix 18:09:03 <dolphm> ayoung: yeah 18:09:04 <dolphm> #topic Reminder: Icehouse feature freeze March 4th (features must be merged) 18:09:17 <dolphm> so we now have exactly two weeks to land all of the outstanding blueprints 18:09:31 <morganfainberg> i think we're on solid track for that 18:09:37 <stevemar> #link for outstanding blueprints: https://launchpad.net/keystone/+milestone/icehouse-3 18:09:41 <dolphm> so for EVERYONE (core or not), if you have free review bandwidth, focus on changes linked to from here: 18:09:49 <dolphm> GOTO stevemar's link 18:09:55 <ayoung> ++ 18:10:06 <stevemar> ctrl+f "needs code review" 18:10:16 <ayoung> is there anything outside of Keystone reviews that are critical to us as ell? 18:10:43 <ayoung> well 18:10:44 <morganfainberg> ayoung, i haven't seen much at the moment. 18:11:05 <dolphm> last i counted we need to be landing about 2 bp-targeted patches a day on average-- i think that's reasonable if we land a bunch of the lower level ones in the next couple days, so we have more time to iterate over the bigger ones like saml consumption and token revocation events 18:11:07 <ayoung> nkinder are there any of the LDAP bugs you've seen that should be targetted at I3? 18:11:36 <ayoung> he's been beating on LDAP lately. We can take the bugs as they are fixed, but would be nice to know which should be targetted. 18:11:39 <dolphm> ayoung: reviews are highest common priority for sure 18:11:51 <ayoung> dolphm, ++ 18:11:52 <stevemar> we'll have 9 in code review once topol 's audit work goes in, it's gating now 18:11:58 <dolphm> ayoung: blueprints first because i'm selfish, and i3 targetted bugs second 18:12:07 <ayoung> ++ 18:12:20 <nkinder> ayoung: Nothing huge. There's one I have submitted for review this morning. 18:12:33 <dolphm> then we have a bug squashing party for a few weeks :) 18:12:54 <henrynash> dolphm: one of mine (bug) wasn't correctly targeted, just updated: #link https://bugs.launchpad.net/keystone/+bug/1226171 18:13:29 <nkinder> ayoung: there's also one that needs to be filed about LDAP syntax violations, which richm is working on. I think he's in testing, so it's getting close. 18:13:29 <dolphm> henrynash: sounds good 18:13:43 <dolphm> nkinder: if it should block icehouse's release, be sure to target i3 18:13:54 <stevemar> pinging mhu for status on limited use trusts 18:13:56 <ayoung> henrynash, how are we looking on the "multiple backends" thing? 18:14:18 <ayoung> is that going to make it? Lots of people are asking for splitting service users from the rest of LDAP 18:14:19 <morganfainberg> ayoung, henrynash, is that a feature or a bug fix at this point? 18:14:21 <henrynash> ayoung: review is up, just had to rebase 18:14:24 <ayoung> ++ 18:14:33 <dolphm> cool 18:14:34 <morganfainberg> henrynash, do we have a bug targeted i3? 18:14:46 <nkinder> dolphm: I'm unclear on the exact criteria for a "blocker", but we can discuss that after the meeting. 18:14:57 <henrynash> morganfainberg: yes, that's the one I listed above 18:15:01 <morganfainberg> ooooh 18:15:03 <henrynash> #link https://bugs.launchpad.net/keystone/+bug/1226171 18:15:08 <dolphm> nkinder: worth defining it now for everyone... 18:15:10 <dstanek> i have some easy reviews for rotating passwords that need to be looked at 18:15:12 <morganfainberg> yeah, i should read more :P 18:15:36 <henrynash> morganfainberg, ayoung: review of it is here: https://review.openstack.org/#/c/74214/ 18:16:20 <dolphm> blocker bugs tend to be new for the current release, critical/high/medium impact, and would impede adoption of icehouse in some way 18:16:21 <morganfainberg> henrynash, thanks! 18:16:44 <dolphm> e.g. "I can't use icehouse because this config option doesn't work anymore." 18:16:48 <morganfainberg> henrynash, aha i didn't see it because i was looking at the grant stuff 18:17:16 <henrynash> morganfainberg: I'll definitely let you off with that excuse :-) 18:17:26 <dolphm> lol 18:17:27 <dolphm> #topic Switch from #openstack-dev to #openstack-keystone ? 18:17:29 <morganfainberg> henrynash, i'll look over both of those today 18:17:43 <topol> morganfainberg always has the right answer... a smooth operator 18:17:46 <nkinder> dolphm: ok, that makes sense 18:17:47 <morganfainberg> there has been some complaints and requests that we do that. 18:17:53 <henrynash> morganfainberg: thx 18:17:55 <morganfainberg> move to the new channel that is. 18:17:59 <dolphm> so, as everyone knows we've tried for a long time to not hide in a project-specific channel, as keystone discussions tend to impact the entire community 18:18:16 <dolphm> but we've made #openstack-dev unusable/distracting for the broader community 18:18:29 <jamielennox> morganfainberg: i see people's point, lots of people would lurk in -keystone anyway 18:18:42 <morganfainberg> jamielennox, yes 18:18:50 <topol> dolphm +++ 18:18:55 <dolphm> if we switch to #openstack-keystone for project-specific discussions, we should still raise to #openstack-dev for design discussions that have community-wide impact (say, renaming projects back to tenants) 18:19:11 <morganfainberg> dolphm, ++ 18:19:26 <dolphm> but otherwise, i'm not opposed to ducking into #openstack-keystone for the majority of the time 18:19:26 <topol> how can folks "lurk in multiple channels"??? 18:19:33 <dolphm> i was curious if anyone had any strong opinion either way 18:19:45 <dolphm> topol: does your client not support more than one channel? 18:19:46 <jamielennox> dolphm: if people care then it's no difference to me 18:19:53 <topol> well if we are annoying folks we should move 18:19:55 <morganfainberg> i think we should just say be sure to be in both, and any topic can be pointed as a "hey this should be -dev topic and rope in others" or go rope in others. 18:20:08 <topol> I use chatzilla. I get lots of tabs 18:20:15 <jamielennox> topol: really? i think i have about 10 on freenode, more internally 18:20:19 <lbragstad> it will also give people a place to find keystone folks so, instead of just saying 'check openstack-dev' 18:20:20 <dolphm> new devs will surely pop up in -dev, even if they're focused on keystone 18:20:27 <morganfainberg> yep. 18:20:42 <topol> something beter than chatzilla? Im so old school 18:20:53 <ayoung> openstack-dev will have nothing but crickets without Keystone 18:20:58 <morganfainberg> i'm happy to get eavesdrop etc added to openstack-keystone (I registeted it to help direct people over to dev a while ago) 18:20:58 <ayoung> chirp 18:21:14 <dolphm> ayoung: that might change after we give it up and people find more room there for cross-project chatter 18:21:22 <ayoung> works for me 18:21:30 <jamielennox> dolphm: i think i'm liking the idea more and more 18:21:36 <morganfainberg> i'll get all the bits takencare of for openstack-keystone today. 18:21:42 <morganfainberg> since i own the channel :) 18:21:48 <dolphm> alrighty then 18:21:49 <dolphm> #action everyone! switch to #openstack-keystone for project-local chatter 18:21:53 <stevemar> YAY 18:22:01 <dolphm> #action morganfainberg to revise the channel topic over there so we're not all confused 18:22:05 <dstanek> topol: weechat or irssi if you are old school 18:22:09 <gyee> s/project-local// 18:22:10 <topol> its like dad bought us a car at age 16 18:22:17 <dolphm> gyee: fair enough 18:22:24 <morganfainberg> i'll also auto voice keystone-core just so it's easy to find us in there. 18:22:29 <morganfainberg> not that ti'll have any impact 18:22:55 <dolphm> #action morganfainberg to do additional IRC things 18:22:57 <morganfainberg> just sticks us at the top. 18:22:57 <gyee> morganfainberg, now you are pushing it :) 18:23:02 <morganfainberg> gyee, LOL 18:23:05 <morganfainberg> gyee, ;) 18:23:10 <dolphm> #topic open discussion 18:23:12 <morganfainberg> gyee, you know you like it 18:23:25 <ayoung> When do we start adding topics for the Juno summit? 18:23:37 <dolphm> ayoung: no clue 18:23:50 <ayoung> BTW...Juno summit hotels list is up, invites are out. If you are going, get your logistics in order 18:23:52 <dolphm> ayoung: seems like that starts after i3's release date, no? 18:24:03 <morganfainberg> I'm at the Omni for the hotel 18:24:04 <dolphm> ayoung: ooh, thanks. i haven't seen that yet 18:24:07 <topol> hotels are fillling up 18:24:15 <topol> big time 18:24:19 <morganfainberg> you can't go wrong with either of the main hotels 18:24:27 <morganfainberg> omni is across the street from the conv. center 18:24:33 <morganfainberg> i recommend it if you want less of a walk 18:24:33 <lbragstad> Omni and Westin are both packed... 18:24:34 <stevemar> topol, where are you at? 18:24:37 <lbragstad> last I checked 18:24:37 <dolphm> omni it si 18:24:41 <ayoung> we got jamielennox approved to go, and I finally get to meet nkinder face to face. RH will be well represented in all things identity and security 18:24:45 <dolphm> lbragstad: boo 18:24:49 <lbragstad> :( 18:24:52 <morganfainberg> lbragstad, it might be the room block is taken, not booked up 18:25:09 <lbragstad> ahh 18:25:10 <ayoung> there is a link throgh the summit page, 18:25:11 <topol> Im at the Westin Peachtree. Got some great memories of tha place from college parties 18:25:11 <morganfainberg> if you can afford a non-discounted (conf. room) you might get omni or westin still 18:25:15 <ayoung> don't contact directly 18:25:33 <topol> lbrgastad dont use the internal tool. call hotel directly 18:25:35 <morganfainberg> topol, i almost went with the westin, i just wanted less of a walk in the morning 18:25:44 <topol> or book via summit site 18:25:47 <ayoung> http://www.eventbrite.co.uk/e/openstack-summit-may-2014-atlanta-tickets-10207692483 18:25:49 <lbragstad> topol: ok 18:26:03 <dstanek> where are the links to the hotels? 18:26:10 <topol> internal tool says booked full. Ignore it 18:26:24 <jamielennox> topol: which is fully booked/ 18:26:25 <ayoung> looking 18:26:32 <stevemar> dstanek, #link https://www.openstack.org/summit/openstack-summit-atlanta-2014/hotels/ 18:26:43 <dstanek> thanks 18:26:52 <morganfainberg> lbragstad, you get to come to the summit too, right?! 18:27:03 <topol> our internal tool said that they were booked and it was wrong 18:27:04 * lbragstad crosses fingers... 18:27:09 <ayoung> #link https://www.openstack.org/summit/openstack-summit-atlanta-2014/hotels/ 18:27:12 <morganfainberg> topol, get lbragstad there!! :) 18:27:13 <dolphm> stevemar: thanks 18:27:17 <ayoung> too slow 18:27:32 <topol> lbragstad should be going. he better let me know if he is told otherwise 18:27:36 <nkinder> jamielennox: did you try going to the hotels through the summit site? 18:28:07 <nkinder> jamielennox: our internal tool said the hotels were booked too, but it works through the summit site link 18:28:17 <jamielennox> nkinder: there had been lots of discussion, was going to talk about it today and book after - i hadn't seen anything full yet 18:28:24 <topol> same team must build our internal tool :-) 18:28:29 <topol> s 18:28:50 <nkinder> internal tools FTL :) 18:29:17 <dolphm> westin appears to have space 18:30:34 <dolphm> topol: i use google's tool, personally. it's open source and supports all of the booking websites equally well in my experience 18:32:01 <morganfainberg> dolphm, ++ 18:32:12 <morganfainberg> if you are an amex/starwood member you can get good deals on westin 18:32:24 <morganfainberg> through amex or starwood site 18:32:26 <morganfainberg> fyi 18:32:43 <morganfainberg> but that is like airline rewards miles. 18:32:44 <topol> yeah, wait till your company gets bigger and you'll find out what we mean by internal tool :-) that must be used if possible 18:32:55 <topol> (its crappy) 18:32:58 <morganfainberg> topol, i used to have to deal with that stuff when i worked for Fox / MySpace 18:33:10 <henrynash> topol: c/mon…..you don't love an IBM 360 UI ? 18:33:13 <morganfainberg> topol, i always found cheaper/better and applied for an exemption, never denied 18:33:44 <dolphm> morganfainberg: that's what i do today 18:34:09 <topol> stop henrynash, stop :-) 18:34:12 <morganfainberg> dolphm, ++ 18:34:20 <ayoung> BTW, for the newer set: I've learned it is worth staying through the end of the Day Friday 18:34:29 <ayoung> I'm flying out Saturday morning 18:34:36 <stevemar> ayoung, ++ 18:34:41 <dstanek> 10 min walk from the Westin doesn't seem bad 18:34:47 <topol> keystone is always shoved to the last day cause dolph won't pay people off for us :-) 18:35:04 <ayoung> Monday may be a wash...but plan on all of us just meeting up in the developer lounge and using Monday as the Keystone Hackfest day 18:35:11 <morganfainberg> ++ 18:35:18 <dolphm> topol: we'll be distributed again, i hope 18:35:23 <henrynash> dolphm, ayoung, morganfainberg: when we're done travel arranging…I do have a question on the multi-domain fix 18:35:30 <morganfainberg> henrynash, sure thing 18:35:30 <ayoung> fire away 18:35:33 <stevemar> monday does seem like a wash 18:35:36 <dolphm> we're also hoping to have a large chunk of time dedicated to cross-project sessions, which will be entirely new for the summit 18:36:32 <henrynash> so the fix only uses a "composite" ID (e.g. user_id + domain_id) IF you are using domain-specifc backends 18:36:55 <henrynash> so no conversion of existing data into the composite ID format 18:37:11 <ayoung> henrynash, ++ 18:37:16 <bknudson> is it like user_id@@domain_id? 18:37:19 <ayoung> that was my suggestion 18:37:27 <dolphm> henrynash: so you can't switch from a single domain backend to multi-domain backend? 18:37:29 <morganfainberg> henrynash, eventually i'd like to convert the data to be consistent. but i don't see a need to do that now 18:37:39 <henrynash> is there any danger that you start single-domain and want to move multi-domain and need to modify existing IDs? 18:37:42 <morganfainberg> actually... that is a good point ^ 18:37:52 <morganfainberg> henrynash, i already have that use case, move from single to multi backend 18:37:54 <ayoung> dolphm, it would need to be deliberate, but if you have an LDAP set up in the main config file, it should still work 18:38:05 <morganfainberg> henrynash, i have customers chomping at the bit for the multi backend 18:38:21 <ayoung> a helper tool for migration can live outside the main code 18:38:24 <morganfainberg> i don't mind if we have some way to do it, but i don't want to hand-write migration 18:38:32 <morganfainberg> yeah, helper tool would be super 18:38:40 <henrynash> dolphm: well, that's my concern…but by definition an you would have to migrate data from one bad 18:38:45 <henrynash> oops 18:38:59 <ayoung> damn you autocorrect 18:39:07 <morganfainberg> it feels like we could write keystone-manage code to do it 18:39:10 <henrynash> so normal case is: you add in a domain for each external LDAP you are using 18:39:12 <morganfainberg> henrynash, ayoung, dolphm, ^ 18:39:20 <dolphm> morganfainberg: that's how we handled diablo -> essex migrations 18:39:21 <morganfainberg> but def. not live-api 18:39:48 <dolphm> keystone-manage dump_diablo > keystone-manage now_build_me_a_real_database 18:40:02 <ayoung> morganfainberg, can be done many ways. It is going to be a one time migration. We can punt on that until after the code works. It doesn't need to be a long term support thing 18:40:28 <morganfainberg> ayoung, ++ 18:40:29 <ayoung> we can even deprecate the LDAP in the main config file approach eventually 18:40:30 <morganfainberg> ok 18:40:42 <ayoung> so that people don't end up in this situation in thefuture 18:40:44 <henrynash> I did consider just converting all the data up front and always running in composite ID mode 18:40:50 <dolphm> ayoung: ++ i'd rather only have one way to support ldap identity backends in juno 18:41:09 <henrynash> there would be almost no change to the new code….just need yo add the migration 18:41:13 <morganfainberg> henrynash, if it isn't a huge effort, that would be good. but if it jeapordizes the code / review /etc not worth it 18:41:31 <morganfainberg> henrynash, i like having consistent data so no special cases needed 18:41:32 <dolphm> henrynash: a tool to "render" out the current LDAP config to a discrete file would be nice too 18:41:34 <morganfainberg> less complexity 18:41:41 <morganfainberg> dolphm, ++++++++ 18:41:54 <henrynash> the consequence would be, however, that everyones userID would "change" over the upgrade 18:42:13 <dolphm> right, as long as that's opt-in on the deployer's part 18:42:28 <morganfainberg> henrynash, yeah, don't auto-migrate 18:42:48 <morganfainberg> i think if we are doing that, we should make it optional for I, perhaps required for J or K? 18:42:52 <ayoung> henrynash, will the existing code continue to work if yoiu enable the multi backend, or will it be either-or 18:42:59 <morganfainberg> as in "yo, this is chaning, but you don't have to yet" 18:43:00 <ayoung> either-or isOK, so long as we are prepared for it 18:43:11 <morganfainberg> same as we do deprecation 18:43:16 <henrynash> ayoung: what do yo mean by "code" 18:43:19 <ayoung> and...will SQL and LDAP work together ? 18:43:29 <henrynash> ayoung: yes, I test that 18:43:46 <ayoung> henrynash, awsome...then we can move to testing LDAP in Gate 18:43:59 <ayoung> IE, our defaulkt setup will be one SQL domain and one LDAP domain 18:44:06 <dolphm> bknudson: can you follow up here - looks like all your concerns were addressed https://review.openstack.org/#/c/60741/ 18:44:39 <bknudson> dolphm: will look at it this afternoon. 18:44:46 <dolphm> bknudson: thanks! 18:45:53 <morganfainberg> really quickly, on the topic of openstack-keystone, please register your name w/ nickserv (openstack-core) so I can give you rights to change topic etc 18:46:09 <bknudson> so we're not going to be able to create grants for users/groups that don't exist? 18:46:39 <ayoung> bknudson, we should be able to, why do you say that? 18:47:01 <ayoung> is that from 60741? 18:47:17 <bknudson> ayoung: I proposed a couple of changes to allow it in some cases which are now -2 18:47:30 <ayoung> by whom? 18:47:31 <bknudson> ayoung: e.g., https://review.openstack.org/#/c/72142/ 18:47:51 <bknudson> ayoung: and for groups: https://review.openstack.org/#/c/72144/ 18:48:07 <bknudson> ayoung: it was dolphm! 18:48:14 <ayoung> ah, dolph, so those changes are going to be essential for landing assignments for Federation. 18:48:35 <ayoung> a user or group is not necessarily going to "exist" in the backend 18:48:35 <dolphm> ayoung: but, they're not - at all 18:48:57 <dolphm> ayoung: i'm not precluding have a sql identity backend for groups 18:49:07 <dolphm> ayoung: are you making a different assumption? 18:49:29 <ayoung> dolphm, my assumption is that, baseline, Federation should be treated as an identity backend with no enuemration 18:49:35 <bknudson> I think it will create an inconsistency between v2 and v3 if we don't fix "create grant when no user" and group. 18:50:19 <bknudson> as in, you can do the grant using v2 api but can't do it with v3 api. 18:50:27 <bknudson> I'd have to try it to be sure. 18:50:29 <dolphm> ayoung: right, it's a trusted source of identity that we can't query 18:51:01 <dolphm> bknudson: if there's a discrepancy there, there shouldn't be 18:51:22 <ayoung> so if I am trying to create role assignments for my organization, I need to be able to do it even if I don't have, say the groups in my SAML assertion 18:51:28 <ayoung> or explicit role assignment for users 18:51:32 <bknudson> right, so need to decide whether we're going to allow it or not and make the fix either to v3 or v2. 18:51:47 <dolphm> ayoung: right, that's where mapping comes in 18:52:09 <ayoung> the second can be handled via mapping, of course, but there still we be no enumeration of groups from mapping, they will just magically appear when a user triggers the mapping 18:52:10 <dolphm> ayoung: you can do whatever you want, and it's way more powerful than assigning roles to users (ephemeral or not) 18:52:34 <dolphm> ayoung: mapping isn't magical... it's quite explicit? 18:52:37 <bknudson> are we going to validate that the group exists when you create the mapping? 18:52:46 <ayoung> dolphm, I mean that there is no "list groups from mapping" functions 18:52:52 <dolphm> stevemar: marekd: ^ i don't recall where that's validated 18:53:12 <dolphm> i assume it'd be after processing, during token generation? 18:53:18 <ayoung> and I think it is going to confuse people to say "no direct assignment of roles to federated users" 18:53:19 <stevemar> dolphm, it should be done in the current patch that we're working on, but it's not 18:53:43 <dolphm> ayoung: i don't think it is 18:53:45 <ayoung> that is really making people rethink how they do things, and will be a lot of overhead for dealing with one-offs 18:54:12 <dolphm> ayoung: and yes, it's a different mental model because the users are just bags of attributes, not identities 18:54:18 <ayoung> If only one person is going to get a role you need to modify mapping, group, and role-assignemnt 18:54:59 <ayoung> lets just drop the hard and fast rule that we check for people in the identity backend and then it works across the board. Retrainig users is ard 18:55:01 <ayoung> hard 18:55:26 <dolphm> ayoung: right- you'd identify the attribute that makes them have the authorization, and map them into the appropriate group 18:56:13 <ayoung> we still need to enumerate groups 18:56:41 <dolphm> ayoung: identity_api.list_groups() ? 18:56:47 <ayoung> nope 18:56:55 <ayoung> won;t work when groups are mapped from federation 18:57:02 <dolphm> ayoung: i don't follow 18:57:17 <dolphm> ayoung: mapping engine outputs a set of groups 18:57:37 <ayoung> to what identity backend? 18:57:45 <ayoung> do we treat mapping as the identity backend? 18:58:16 <dolphm> ayoung: i'm not really sure it matters for icehouse - it's up to the deployer 18:58:21 <bknudson> mapping has to generate user IDs with domain ID in them for multi-ldap. 18:58:24 <dolphm> and no, mapping is not an identity backend 18:58:36 <ayoung> dolphm, we won't be able to assign groups to APIs if we check for the existence of groups in the identity backend 18:58:44 <stevemar> dolphm, bknudson actually, we do verify groups exist, well, we query it anyway, when trying to get roles to assign 18:58:49 <dolphm> bknudson: you mean group IDs with domain IDs in them? 18:58:58 <morganfainberg> dolphm, 2min 18:59:08 <dolphm> bknudson: because the user IDs it produces are just garbage for logging, AFAICT 18:59:11 <dolphm> there's no use case for them 18:59:23 <dolphm> stevemar: that's what i figured 18:59:29 <dolphm> morganfainberg: thanks 18:59:30 <bknudson> dolphm: right, it'll be group ID that includes domain ID... probably just hard-coded in the mapping. 19:00:00 * dolphm switching to #openstack-keystone :D 19:00:03 <dolphm> #endmeeting