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