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