16:00:42 #startmeeting keystone 16:00:42 Meeting started Tue Jan 22 16:00:42 2019 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:46 The meeting name has been set to 'keystone' 16:00:50 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 16:00:51 agenda ^ 16:00:53 o/ 16:00:56 * cmurphy in double meetings 16:00:56 hola 16:01:04 o/ 16:01:09 o/ 16:01:18 hi wxy| ! 16:01:19 :) 16:01:29 kmalloc: welcome back~ 16:01:32 o/ 16:01:32 o/ 16:01:52 thanks! :) 16:02:09 we have quite a bit to get through today 16:02:13 * ayoung mentally pronounces wxy| as Waxy. 16:02:18 so we'll go ahead and get started 16:02:22 #topic Announcements 16:02:30 #info Feature proposal freeze is next week 16:02:43 I *think* all features have code in review, which is good 16:02:53 ayoung: so i'm hearing the boston accent with that pronunciation (at least in my head) 16:02:59 #info Feature freeze is 6 weeks out 16:03:02 lbragstad: nice. that is good news 16:03:15 so - this one concerns me a bit mroe 16:03:31 especially with gate status over the last release 16:03:48 and there are a lot of things that need review 16:03:52 realistically we can push things through past the freeze if it's just gate failures 16:04:21 we can - but it takes away from time we spend firming up the release 16:04:35 we have plenty of time on that front 16:04:36 wxy|, https://review.openstack.org/#/c/605235/ is easy except for updating the error message 16:04:36 really 16:04:40 just something to be mindful of 16:04:58 if the code is really just a gate failure, it should not be subjected to feature freeze 16:05:16 also - the PTL self-nomination period starts in 6 weeks 16:05:33 lbragstad, this your last go-round? 16:05:40 if you're thinking about running and would like some more information about the role or have questions in general, please don't hesitate to reach out 16:06:20 i've always been a proponent that leadership changes are healthy 16:07:16 just something to think about as we get closer to that date 16:07:24 #topic Previous action items 16:07:45 people should be encouraged to run even if lance is running again 16:07:47 last week we had an action item to go through the TC vision statement and red line it 16:07:52 kmalloc ++ 16:08:13 cmurphy put together some notes 16:08:15 however, i would like to have lance let us know earlier rather than at the wire if he is planning to run (he may of course change his mind) 16:08:16 #link https://etherpad.openstack.org/p/keystone-technical-vision-notes 16:08:33 kmalloc at this point, i'm not planning on it 16:08:53 lbragstad: thanks for the clarification 16:09:29 so - i'd like for us to go through what is in that etherpad 16:09:34 and treat it like a discussion 16:09:56 Self service is fairly close to non-existant in OpenStack 16:10:06 ultimately, we'll be putting a version of that into our contributor guide 16:10:08 I mean, in Keystone 16:10:12 I also pasted some points that satisfies the pillars of cloud https://etherpad.openstack.org/p/vision 16:10:24 ayoung right - keep in mind this is a vision statement 16:10:26 If we are going to embrace that, we need to be serious and talk it through 16:10:39 and is designed to help us make decisions that enable it 16:11:13 A user needs to be able to create a project, and needs to be able to delete a project. And they need to have all their resources cleaned up when they do that. That is baseline for Azure an AWS, and so far from what we can do in OpenStack 16:11:40 ayoung: with a drive towards a full featured idp, self service is much more important than the early-on design of keystone 16:12:28 * knikolla will read back on the meeting logs. Getting on a plane from ROC to BOS. 16:12:35 right - the idea here is to just get agreement on the specifics of keystone's vision (since it's more detailed than what is in the openstack cloud vision) 16:12:39 I'm not making that connection. I mean, I agree, but how is that due to IdP? 16:12:40 knikolla have a safe flight 16:13:06 safe flight knikolla 16:13:52 ayoung: because we can't rely on an external project to do it for us. a real full-featured service allows for at least grantable self-service in my view 16:14:26 So what you are saying is "now it is time to to all the things right.?" 16:14:29 it may not be the default behavior (to begin with) but it shouldn't be arcane invocations to allow it to happen. 16:15:00 The resource cleanup is my nightmare, but OK 16:15:19 if we're making big changes, don't stop short 16:15:49 not so much "just do it" or "do it all the things right" (we can aspire to that last one... but we might miss) 16:16:39 is there anything in that etherpad that people disagree with from a vision-perspective? 16:17:42 Nope, it is good as far as it goes. 16:17:44 it looks good to me. 16:17:49 even if there is - i wouldn't be opposed to getting this into review, so we can iterate on it there 16:18:21 we should make it a habit to come back to this every release and keep it in check 16:18:31 but if people don't have anything major here, we can move on 16:19:15 #topic Stein Features 16:19:29 this is just a touch point based on what we've committed to for the release 16:19:48 I think ayoung has an implementation up for explicit domain ids? 16:20:08 yeah, there is a problem with error messages so I've had to leave it for a bit 16:20:19 its dumb and I should have solved it already 16:20:20 but... 16:20:24 no major blockers? 16:20:32 https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L225 16:20:46 if someone wants to swat it, I'd appreciate 16:20:53 good to know 16:21:03 right now, it gives the wrong error, as wxy| noted 16:21:15 ack 16:21:22 But to fix, I need to know why we got a conflict error, which is more of a rewrite than I wanted to do 16:21:44 oh. huh 16:21:49 maybe I could make one message for both? 16:21:54 "Now it always says the name is duplicated even using different name but the same id." 16:22:23 it should be super simple to check why there is a conflict. 16:22:37 but if not, feel free to say "name or id is duplicated" 16:22:46 we've done similar in the past. 16:23:02 I think for now I'll do that, and we can fix it after it merges and one of us goes "Duhr...it shouod have benn..." 16:23:25 i'll make sure to poke at that when i review it 16:23:47 i'll look at the conflict exception 16:23:51 it might already be bubbled up for us. 16:23:56 otherwise - no major blockers i assume? 16:24:00 or the SQL-A bit(s) 16:25:19 ok - moving on 16:25:29 wxy| has reviews up for domain limit support 16:25:37 and they are looking pretty good 16:26:07 lbragstad: have to refresh the patches according to your comments. 16:26:24 afaict, i'm not seeing anything major that should block this, but more eyes would be good 16:26:31 I'll do that later. 16:26:44 awesome - i'll take another look this week then 16:27:11 cmurphy has WIP patches up for app creds 16:27:16 and capability lists 16:27:24 W00t! 16:27:33 i'm not sure if she's looking for reviews yet 16:27:48 but something to keep tabs on 16:28:03 or check out and play with locally 16:28:18 i have a series of patches up for the JWS token provider 16:28:25 and they are ready for review 16:28:38 cool. I'll look 16:28:54 i spent last week digging into the crypto stuff and checking on some things for jwt based on the PyJWT implementation 16:29:06 i've proposed updates to the specification - and rewrote the implementation accordingly 16:29:17 feedback is welcome 16:29:32 last feature we have a specification for is MFA receipts 16:29:46 which is only waiting on documentation 16:29:57 #link https://review.openstack.org/#/c/580535/ 16:30:18 but that's it for formal feature work 16:30:26 any questions, comments, or concerns here? 16:31:23 alright - moving on 16:31:30 #topic Reviews that need attention 16:31:47 does anyone have patches they need eyes on? 16:32:49 outside of what we've already talked about? 16:32:51 Aside from that one that languished.... 16:33:08 I'd like you to remove the -1 from the other id based on... 16:34:01 https://review.openstack.org/#/c/605169/ 16:34:08 ah - just pulled it up 16:34:13 There is nothing wrong with provider-to-provider calls 16:34:36 Providers are our own abstraction for things we can swap out, and in this case, the id as a provider is the right abstraction 16:34:40 my concerns wasn't provider to provider 16:34:51 that was the comment 16:34:55 my concern was backend to provider 16:34:58 no it is a driver -> provider 16:35:06 and this is an exceptional case, imo 16:35:20 I need some eyes on https://review.openstack.org/#/c/588211/ 16:35:52 vishakha cool - i saw that get updated, i can take another look 16:35:54 lbragstad: we should generally move id generation up higher. 16:36:02 but it's a bit of a mess right now. 16:36:03 kmalloc what makes this exceptional in your opinion? 16:36:06 lbragstad: Thanks 16:36:16 the nature of how ids are generated in general 16:36:29 in trying to keep that change as small as possible moving it up is a lot more code 16:36:34 i'd rather see it as a separate cleanup 16:36:38 if that makes sense. 16:36:48 cmurphy, I think that vishakha 's request is really for you, as he addressed you comments mostly in his last commit? 16:36:50 and cover all id generation, pass ids down to the driver consistently 16:36:55 kmalloc, yeah, agreed. 16:37:08 i need to look at the id generation code 16:37:15 the alternative is to change the method signature everywhere to pass in the id 16:37:22 sure. just in general driver should *never* generate ids 16:37:24 and...there is not much benefit to that. 16:37:41 we should fix that, and the manager should always pass down the id. 16:37:47 explicitly everywhere 16:37:49 Exactly, so it is better to get the IDs from the id generator directly. 16:37:52 ayoung: its she not he :) 16:37:53 but that is a bigger change. 16:38:02 vishakha, my apologies 16:38:10 and...good to meet yoou! 16:38:19 ayoung: yes i'll take a look soon 16:38:20 * ayoung has been out of it for too long 16:38:20 ayoung: same here 16:38:31 vishakha, you coming to Denver? 16:38:35 * kmalloc is happy to return with new faces at the meeting 16:38:42 oh man, that's coming up soon isn't it? 16:38:50 ayuh 16:38:55 i need to make sure i have travel funding for that and book it/tickets 16:39:07 ayoung: I hope a session of mine is selected. Then I will be there for sure 16:39:13 ++ 16:39:30 vishakha: well good luck! hope your session is selected and it makes it easier to join us :) 16:39:34 kmalloc, ROAD TRIP...Oh Wait, you are on the wrong coast, damnit 16:39:37 kmalloc: thanks. Nice to meet you too 16:39:56 ayoung: fly to seattle, hope brie will join and we can drive again :P 16:40:05 ayoung i'll take another look - i need to see the id generation stuff 16:40:14 but we only have 1 car now... so if she doesn't join... anyway... talk later. 16:40:29 lbragstad, sounds good. 16:40:31 ayoung thanks for bringing it up again 16:40:50 anyone else have reviews that need attention besides ayoung and vishakha ? 16:41:05 lbragstad, Iguess the other thing is to fix this one 16:41:29 https://review.openstack.org/#/c/623117/ 16:41:56 * lbragstad nods 16:42:00 that was a quick spike to externalize the id generation 16:43:06 ok - looks like it needs some cleanup, but we're targeting it for stein? 16:43:30 lbragstad, that is the alternative way. I would rather not 16:43:43 oh 16:43:44 I think some of those test failures are significant 16:44:03 i'll keep tabs on it and revisit it if you come back to it 16:44:08 But we can do that longer term if we want to externalize ALL of the Id generation like kmalloc suggested 16:44:15 got it 16:44:22 and we should. 16:44:33 but that should be a consistency fix across all of keystone 16:44:50 ok 16:44:50 Lets put that on the Train then 16:44:55 not in the Stein 16:44:58 :) 16:45:00 ++ 16:45:06 damn you beat me to the joke :P 16:45:11 i was typing the same exact thing. 16:45:28 i have some reviews i'd like to get feedback on 16:45:30 #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles 16:45:38 "For all our mutual experience our separate conclusions are the same." 16:45:59 most of those are trying to address #link https://bugs.launchpad.net/keystone/+bugs?field.tag=policy 16:46:02 Wow 16:46:20 i'm hesitant to push more until some of those start merging 16:46:44 but the majority of them are strings of 5 - 6 patches 16:46:54 lbragstad, I'll commit to moving them along 16:47:18 if anyone has questions - i'm available to help walk folks through the approach 16:47:26 vishakha has been helping on that front, too 16:48:00 I should be able to help there 16:48:02 we have a few topics left 16:48:05 lbragstad: I updated the role assignment patch too. https://review.openstack.org/#/c/609210/. You can have a look 16:48:13 vishakha will do - thanks! 16:48:26 if that's it for reviews, we can move on 16:48:36 #topic Launchpad 16:48:47 I haven't been doing a good job of keeping launchpad in check this release 16:49:03 i'll be trying to get things back in order over the next week or two 16:49:28 really just going through and updating closed bugs with appropriate milestones 16:49:32 and doing triage 16:49:46 if that's a process that interests you, just ping me 16:49:54 #topic Athenz plugin update 16:49:56 lbragstad, why is create_user system admin and not domain admin? 16:50:17 * ayoung too slow 16:50:24 ayoung sorry - lets sync after 16:50:27 ++ 16:50:37 james, from oath, it currently swamped in other things 16:50:54 he was going to take a stab at drafting a spec for the athenz plugin oath open-sourced 16:50:55 I got it anyway 16:51:22 today in the edge call, ildikov suggested that we consider drafting something and having him review it instead 16:51:38 i put this on the agenda to see if there are other interested parties 16:51:53 knikolla has nothing better to do now 16:52:04 ftr - this would clearly be something we would target for Train 16:52:30 What would be the use case? 16:52:50 adding Oath to an existing deployment. or making it easier for Yahoo to work with OpenStack? 16:52:51 athenz is an identity provider that issues tokens and x.509 certificates 16:53:11 That is all Federation, tho 16:53:16 right 16:53:38 the general idea is to investigate generalizing the shadow mapping work we have in keystone 16:53:51 and instead of only having those properties come from SAML 16:54:02 they could come from something like a certificate 16:54:04 i did some investigation and keystone is already capable of this without any changes 16:54:17 cmurphy oh - nice! 16:54:36 https://docs.openstack.org/keystone/latest/admin/external-authentication.html 16:55:50 cmurphy would we still need a way to send attributes from a cert to the shadow mapping? 16:56:31 we need to update our docs because the meat of how it works is in here https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html except that tokenless auth itself doesn't work that well right now 16:56:45 any attributes in an assertion can show up in Keystone if the module can pass them 16:56:47 the mapping picks up the attributes from mod_ssl 16:57:20 so this helps for athenz but it doesn't help at all for edge because you still need to auth with keystone 16:59:31 tokenless was such a good idea 16:59:37 we need to use that like, everywhere 16:59:39 we can talk about it more after the meeting 16:59:45 right now, athenz wraps the shadow mapping work we did, but what we have today with x.509 isn't a drop-in replacement? 17:00:00 So...assuming wee fix tokenless, what do we need to do? 17:00:10 lbragstad: i think it is a drop-in replacement for what they do 17:00:18 ayoung: https://bugs.launchpad.net/keystone/+bug/1811605 firt 17:00:19 Launchpad bug 1811605 in OpenStack Identity (keystone) "Tokenless authentication is broken" [Undecided,New] 17:00:21 first* 17:00:34 ack - let's move to -keystone 17:00:37 and then it seems like the middleware component was never fully working 17:00:42 or i couldn't get it to work 17:00:57 thanks for the time, everyone! 17:01:01 #endmeeting