16:00:39 <lbragstad> #startmeeting keystone
16:00:40 <openstack> Meeting started Tue Oct 30 16:00:39 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:44 <openstack> The meeting name has been set to 'keystone'
16:00:50 <hrybacki> o/
16:00:56 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:57 <cmurphy> o/
16:00:58 <lbragstad> agenda ^
16:01:00 <knikolla> o/
16:01:55 <kmalloc> o/
16:02:21 <gagehugo> o/
16:02:36 <lbragstad> give folks another 30 seconds
16:02:52 * kmalloc drinks more coffee while waiting
16:02:58 <wxy|> o/
16:03:17 <lbragstad> #topic TC Vision Feedback
16:03:22 <lbragstad> in case you haven't seen it
16:03:26 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2018-October/136034.html
16:03:31 <lbragstad> applies to us
16:03:51 <lbragstad> if you have opinions, comments, questions, or concerns, feel free to weigh in
16:04:12 <lbragstad> #topic Athenz and Auto Provisioning
16:04:18 <lbragstad> #link https://etherpad.openstack.org/p/keystone-shadow-mapping-athenz-delta
16:04:26 <lbragstad> penick posted responses to questions in there
16:04:42 <kmalloc> nice
16:04:59 <lbragstad> depending on his availability, we might see if we can get him in our meeting next week if we have more questions
16:05:21 <lbragstad> he did offer to participate in a hangout/vc if people find that useful
16:05:48 <lbragstad> feel free to weigh in on the approach, or leave comments about what might be feasible to upstream into keystone's auto-provisioning implementation
16:06:35 <lbragstad> does anyone have immediate questions on this topic?
16:07:04 <lbragstad> ok - moving on
16:07:12 <lbragstad> #topic Dead Code/Doc Cleanup
16:07:13 <lbragstad> kmalloc o/
16:07:27 <kmalloc> take a look at the links on the agenda
16:07:38 <kmalloc> a few of us have been on a "clean up the dead code" kick
16:07:46 <kmalloc> (notably wxy| cmurphy and myself)
16:08:01 <kmalloc> this is removing a lot of ancient stuff we don't need anymore
16:08:07 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystonemiddleware+branch:master+topic:bug/1649735
16:08:12 <lbragstad> #link https://review.openstack.org/#/c/614172/
16:08:15 <hrybacki> infinite++
16:08:18 <lbragstad> #link https://review.openstack.org/#/c/612625/4
16:08:23 <kmalloc> there will be more
16:08:24 <lbragstad> #link https://review.openstack.org/#/c/613218/1
16:08:31 <lbragstad> #link https://review.openstack.org/#/c/613513/3
16:08:37 <lbragstad> thanks kmalloc cmurphy wxy|
16:08:38 <kmalloc> but this is very much something we need to keep our eyes on
16:08:51 <kmalloc> old code causes weird problems
16:08:54 <knikolla> awesome!
16:09:03 <kmalloc> like spamming the keystone server for the revocation list that is a 410 now
16:09:09 <kmalloc> (KSM)
16:10:06 <kmalloc> so, if you see code that needs to go
16:10:09 <kmalloc> spin a quick pack
16:10:11 <kmalloc> patch*
16:10:31 <kmalloc> while i like these as low-hanging fruit, clearly we have to still do the cleanup even if we don't have someone picking them up
16:10:54 <kmalloc> so, my opinion is we should just clean some stuff up ever now and again
16:11:02 <kmalloc> espeically the big ones like PKI[z] support in KSM
16:11:10 <lbragstad> makes sense - i'll review those patches today
16:11:15 <kmalloc> because it removes a lot of bitrot code
16:11:32 <kmalloc> and less to maintain is good for us(tm)
16:13:19 <lbragstad> any other patches to note regarding dead code?
16:13:50 <kmalloc> nothing yet
16:13:52 <lbragstad> #topic Bug Smash
16:14:03 <lbragstad> kmalloc?
16:14:04 <knikolla> wondering how a "dead code" halloween costume would look like
16:14:19 <gagehugo> (un)dead code
16:14:20 <kmalloc> I went through and triaged/smashed/closed/etc a TON of bugs across our projects
16:14:36 <cmurphy> I reopened a couple of those btw
16:14:37 <kmalloc> if i mis-closed a bug, please don't hesitate to open it back up (cmurphy caught a few)
16:14:41 <cmurphy> :)
16:14:42 <kmalloc> cmurphy: :)
16:15:07 <kmalloc> also don't hesitate to be aggressive about closing/marking bugs as incomplete if they need more info
16:15:15 <kmalloc> I'd like to see us down under 100 bugs for keystone by end of stien
16:15:19 <kmalloc> we're at ~130ish
16:15:39 <lbragstad> yeah - we've been trending higher over the last 180ish days...
16:15:40 <kmalloc> most of them are small amounts of code to fix, e.g. https://review.openstack.org/#/c/613633/
16:15:57 <kmalloc> but it's not exactly "easy" to figure out what needs to be done
16:16:10 <kmalloc> another example:
16:16:13 <kmalloc> #link https://review.openstack.org/#/c/613455/
16:16:27 <kmalloc> just long running bugs we should bubble to the top of our lists
16:17:02 <kmalloc> most of the other projects are in the single digit or sub 30 bugs
16:17:11 <kmalloc> other = our other, aka not-server
16:17:30 <kmalloc> some are really in depth, i expect those to take longer
16:17:37 <lbragstad> it would be nice to have keystone server under 100 by the time we release stein
16:17:49 <gagehugo> we did finally fix that one doc issue about the port # that would be re-opened as a new bug at least once a week
16:17:51 <kmalloc> but we have mostly been letting bugs sit, and either they are not relevant (we aren't going to fix) or we should fix them
16:18:03 <kmalloc> gagehugo: we have a lot of doc bugs
16:18:08 <kmalloc> those are really unfun to fix
16:18:09 <kmalloc> :(
16:18:24 <lbragstad> we have a lot of documentation work in general
16:18:43 <kmalloc> i'd like to get us to really consider a bug-zero target
16:18:53 <lbragstad> especially the duplication from the Great Doc Migration in Pike
16:19:11 <kmalloc> meaning, all bugs are actively worked on (longer bugs) or have fixes proposed
16:19:25 <kmalloc> or are in an incomplete/need more data state
16:19:45 <kmalloc> e.g. the awful admin-ness bug wont be closed until scope_type work is done
16:20:03 <kmalloc> i don't expect bug-zero in stien
16:20:04 <lbragstad> which we're planning to get done in stein
16:20:23 <kmalloc> but we should aim to knock down to sub 100, if we are sub 100 this cycle we can aim for sub 50 next
16:20:32 <kmalloc> and if we are 50 or under, i think bug-zero is a real target
16:20:41 <lbragstad> half of the scope_types bugs are in progress
16:20:43 <lbragstad> #link https://bugs.launchpad.net/keystone/+bugs?field.tag=policy
16:20:46 <kmalloc> ++
16:21:06 <lbragstad> thanks to vishakha for helping out there
16:22:27 <kmalloc> vishakha has been working on a bunch of bugs
16:22:30 <kmalloc> it's fantastic
16:22:44 <cmurphy> I've been looking for interesting low-hanging-fruit tasks for all the outreachy applicants, if any of these bugs are easy fixes but missing the low-hanging-fruit tag please add it, or if any of them could maybe be broken down into smaller tasks that a newbie could do please let me know
16:22:45 <kmalloc> we also have had some wonderful outreachy-potential folks stepping in on the low hanging ones
16:22:57 <kmalloc> cmurphy: ++
16:23:10 <cmurphy> i had to remove the low-hanging-fruit from a couple of troll bugs
16:23:12 <lbragstad> thanks for helping with that kmalloc and cmurphy
16:23:32 <lbragstad> cmurphy do you remember which ones?
16:24:06 <cmurphy> https://bugs.launchpad.net/keystone/+bug/1570463 https://bugs.launchpad.net/keystone/+bug/1579659
16:24:06 <openstack> Launchpad bug 1570463 in OpenStack Identity (keystone) "RFE: keystone-manage CLI to allow using syslog & specific log files" [Medium,Incomplete] - Assigned to Maram El-Salamouny (maramelsalamouny)
16:24:07 <openstack> Launchpad bug 1579659 in OpenStack Identity (keystone) "oauth login silently ignores scope" [Medium,Triaged] - Assigned to omkar_telee (omkar-telee)
16:24:42 * kmalloc would close that first bug as "wont fix" tbh
16:25:01 <kmalloc> you can totally pipe output to the syslog injector binary
16:25:14 <cmurphy> i was trying to figure out if it's already fixed
16:25:26 <kmalloc> it might be with keystone's log.conf
16:25:48 <kmalloc> but i would just say pipe to logger
16:26:02 <kmalloc> that would be the way i'd do it in any environment i manage
16:26:10 <kmalloc> because configuring keystone-manage sounds like a TON of work
16:26:13 <cmurphy> triaging the bug isn't the topic ;)
16:26:17 <kmalloc> anyway
16:26:39 <lbragstad> anything else we want to cover on bugs
16:26:40 <lbragstad> ?
16:26:56 <kmalloc> we should re-visit friday-bug-day
16:27:01 <kmalloc> just make sure all bugs are triaged
16:27:13 <kmalloc> post summit*
16:27:17 <kmalloc> not pre-summit
16:27:18 <kmalloc> :P
16:27:27 <lbragstad> mm
16:27:41 <lbragstad> we moved away from friday's because of $reasons
16:27:43 <kmalloc> the weekly bug smash did keep bugs at least with eyes.
16:27:46 <kmalloc> could be any day
16:27:52 <lbragstad> but i wouldn't be opposed to focusing on bugs during office hours
16:27:57 <kmalloc> just a weekly "hey folks, triage bugs"
16:27:57 <lbragstad> if question queues are down
16:28:13 <hrybacki> ++ pragmatic
16:28:18 <kmalloc> just once a week make sure new bugs haven't lingered for months.
16:28:21 <kmalloc> or weeks
16:28:25 <lbragstad> sure
16:28:26 <kmalloc> or well longer :P
16:28:34 <kmalloc> obviously more triaging is good
16:28:40 <lbragstad> i notice several other projects use their weekly meetings to do group triage
16:29:01 <kmalloc> 1st hour of office hours == quick triage?
16:29:05 <lbragstad> that's not something we've typically done, but i wouldn't mind spreading the triage knowledge around a bit
16:29:09 <hrybacki> dumb question -- is there anything like an sla between cores and community wrt bug responses?
16:29:26 <kmalloc> hrybacki: typically no
16:29:46 <cmurphy> hrybacki: it's not just "cores" who are responsible for bugs
16:29:56 <kmalloc> anyone may triage bugs.
16:30:01 <lbragstad> hrybacki sla as in the community must respond to bugs within X days or something like that?
16:30:13 <cmurphy> kmalloc: or fix them
16:30:15 <kmalloc> and sometimes reporter needs to supply more info
16:30:18 <kmalloc> cmurphy: ++
16:30:25 <hrybacki> not what I meant -- but if there was something they'd have to pin it to /a/ group
16:30:34 <hrybacki> lbragstad: aye
16:30:39 <kmalloc> there is no set SLA in that regard
16:30:44 <hrybacki> ack
16:30:55 <lbragstad> part of the Apache2 license covers part of that
16:31:02 * kmalloc is done harping on bugs.
16:31:03 <kmalloc> :)
16:31:04 <kmalloc> thanks all!
16:31:09 <ayoung> There is only one bug I care about
16:31:12 <hrybacki> interesting /me notes a review
16:31:17 <hrybacki> lol ayoung
16:31:23 <hrybacki> which one?
16:31:30 <cmurphy> lol
16:31:30 * hrybacki ducks
16:31:34 <ayoung> I'm a man with a one track mind.  So much to do in one lifetime....
16:31:50 <lbragstad> hrybacki you're playing with fire
16:31:56 <knikolla> haha
16:32:02 * hrybacki runs and hides
16:32:05 <ayoung> Not a man for compromise and where's and why's and living lies
16:32:16 * lbragstad braces himself for an ayoung rant
16:32:16 <lbragstad> ;)
16:32:23 <ayoung> https://www.youtube.com/watch?v=hFDcoX7s6rE
16:32:44 <ayoung> Just excited for Bohemian Rhapsody this weekend, actually.
16:32:52 <kmalloc> hrybacki: don't encourage it :P
16:33:06 <ayoung> :)
16:33:10 <kmalloc> ayoung: i've heard VERY good things, but lets talk about that outside of the meeting
16:33:11 <lbragstad> oh - i know
16:33:11 <hrybacki> I'll stop poking the ants nest
16:33:15 <lbragstad> i want to see that movie so bad
16:33:37 <lbragstad> alrighty - moving
16:33:38 <lbragstad> on
16:33:43 <lbragstad> #topic KSA Rate Limiting
16:33:47 <lbragstad> kmalloc o/ again?
16:33:50 <kmalloc> This needs tests.
16:33:51 <kmalloc> BUT
16:33:59 <kmalloc> I want eyes on this to see if this belongs in ksa
16:34:02 <kmalloc> I think it is worthwhile
16:34:09 <kmalloc> but it could go up in SDK instead
16:34:19 <kmalloc> this implements ratelimiting mechanisms in KSA itself
16:34:20 <ayoung> KSA?
16:34:23 <kmalloc> keystoneauth
16:34:24 <ayoung> Why on the client side?
16:34:39 <kmalloc> so the client can say "i don't want to overload X server"
16:34:39 <ayoung> KSA2?
16:34:47 <ayoung> hmmm
16:34:52 <kmalloc> or "we might get locked out if we ask too many times, so please don't ask too many times"
16:34:59 <ayoung> LIke LDAP?
16:35:09 <kmalloc> this is allowing the client to limit their requests to <any> service
16:35:27 <kmalloc> not just assuming the server will be pleasant about it
16:35:43 <kmalloc> nodepool specifically needs this kind of functionality, but if nodepool does it is likely someone else does too
16:35:48 <ayoung> When you say it that way, it sounds like SDK
16:36:01 <kmalloc> and the lower the level it is supported the easier it is to maintain
16:36:04 <cmurphy> I sort of grimaced at it but mordred made the point that there is already retry logic in ksa
16:36:06 <kmalloc> not everything uses SDK.
16:36:16 <kmalloc> and KSA does have.. yes what cmurphy said
16:36:22 <cmurphy> so rate limiting sort of goes with that
16:36:26 <mordred> I didn't do it
16:36:28 * mordred reads
16:36:28 <lbragstad> makes sense
16:36:37 <kmalloc> so, please +1/+2/-1 (please do not -2, we're not at that point yet)
16:36:45 <ayoung> not everything uses KSA either.  CloudForms goes with Fog
16:36:51 <kmalloc> i'd like eyes and comments.
16:37:02 <mordred> so - the reason I think it needs to be in ksa and not sdk (where it is now)
16:37:02 <kmalloc> ayoung: aye, but most things python use KSA
16:37:11 <mordred> is that automatic retries are handled at the ksa layer
16:37:21 <mordred> and so are invisible as requests to the sdk layer
16:37:29 <ayoung> Ok.
16:38:09 * knikolla pokes mordred: we should talk about the summit talk at some point soon
16:38:14 <mordred> knikolla: yeah. :)
16:38:38 <kmalloc> mordred: and i largely agree, but want the other keystone folks to have eyes on it
16:38:43 <kmalloc> and it will have tests before it lands
16:38:50 * lbragstad makes a note to review
16:38:58 <ayoung> What will it break to have it in KSA?
16:39:01 <mordred> also - fwiw - the code allows two things - client-side rate limiting, as well as concurrency limiting - we have found that both are essential in real-world use like nodepool
16:39:04 <kmalloc> but, right now just looking at "is this a good idea and a good impl" is what we wanty
16:39:11 <kmalloc> ayoung: should break nothing, it's opt-in use only
16:39:16 <mordred> ayoung: nothing. it should be completely no-op if you don't opt-in
16:39:23 <kmalloc> ayoung: as it should be
16:39:53 <ayoung> Just to complete the thought...if this is so important, should it be OPT in, or is that only due to paranoia?
16:40:14 <kmalloc> it must be opt in, because you want the client to specify how limited things should be
16:40:20 <kmalloc> many times a couple simple retries isn't bad
16:40:36 <kmalloc> the client/consumer is the only thing that can know how limited the rate of requests should be
16:40:42 <mordred> yeah - it's extra overhead that many people don't need - but if you're at scale, you will need it
16:40:47 <kmalloc> if it's a "this might break the server" case, the server should protect itself
16:40:55 <kmalloc> (different story)
16:40:56 <mordred> 'should'
16:41:09 <kmalloc> yeah, so not opening THAT can of worms right now
16:41:20 * mordred flexes arms and remembers crashing public clouds before having implemented client-side rate limiting :)
16:42:13 <lbragstad> anything else on this topic?
16:42:15 <ayoung> OK...we'll look with appropriate understaning now.  Anything else on that?
16:42:24 <kmalloc> nope.
16:42:31 <lbragstad> #topic open discussion
16:42:33 <kmalloc> except please do not -2 ;)
16:42:54 <lbragstad> floor is open
16:43:09 <cmurphy> Like I mentioned before I'm looking for good low hanging fruit tasks for newbies to get their hands dirty without having a lot of keystone context
16:43:20 <cmurphy> so if you can think of any or run across any let me know
16:43:33 <lbragstad> i'll keep my eyes open
16:43:36 <ayoung> cmurphy, so, my advice to people lately has been to start with code reviews, not bug fixes
16:43:46 <ayoung> find some thing they understand, and ask questions.
16:43:55 <ayoung> No +1-1 required
16:44:21 <cmurphy> ayoung: that's a good point
16:44:24 <kmalloc> ayoung: that has always been my recommendation
16:44:30 <ayoung> and those questions usually lead to a discussion, which leads to the original poster sometimes saying "hey that is a good idea."
16:44:38 <kmalloc> however, a lot of recent code reviews have been ... a little dense :)
16:44:47 <kmalloc> i think we're through the worst of that for now.
16:44:49 <cmurphy> yeah, it would be a little flood-gate-y
16:45:30 <ayoung> If they want, and the author agrees, they can make that change for the original poster by updating the patch, and there there they go...
16:45:47 <ayoung> Great for Typos, and doc changes esp
16:46:03 <kmalloc> also followup patches for nits/typos are good
16:46:27 <kmalloc> 100% would support someone wanting to submit their own patch to fix the things if they so desired like that
16:46:31 <ayoung> kmalloc, I wish that had always been the norm here....sometimes I miss Brant,  sometimes I don't
16:47:51 <lbragstad> slightly unrelated - but i have a couple patches up to oslo.context and oslo.policy that will make the scope_types work in keystone easier
16:48:01 <lbragstad> #link https://review.openstack.org/#/c/611443/
16:48:03 <cmurphy> so I'll definitely keep this in mind but also being able to see your code land is really motivating especially since a lot of these people are students
16:48:05 <ayoung> lbragstad, oooh, so does ozz
16:48:08 <lbragstad> #link https://review.openstack.org/#/c/613635/
16:48:21 <lbragstad> and #link https://review.openstack.org/#/c/614195/
16:48:50 <lbragstad> those things should make it easier for us to do complete user management with scope-types
16:49:02 <lbragstad> (like the demo i did a week or two ago)
16:49:11 <ayoung> I like, in general
16:49:43 <ayoung> https://review.openstack.org/#/c/613313/
16:50:05 <ayoung> That allows a much wider set of testing.  One thing  we can't do now:  check if the right project ID was set
16:50:12 <lbragstad> nice - i'm on that review
16:50:29 <kmalloc> yeah that one has been on my list for a couple days
16:50:37 <ayoung> like, we only cjheck the ID from the token, and assume a match.  That one thos, goes much further and allows a lot of target stuff
16:50:45 <ayoung> the one things we don't do is test via oslo-context.
16:51:16 <ayoung> I'm working on a unit test for the checker code, so we can build it out for this one
16:52:25 <ayoung> coding features so you can talk about them during presentation in the summit is an interesting dynamic.  Its like "How should we do this right...oh, we need that..."
16:53:04 <kmalloc> we should also expose the flatten mechanism as part of the policy check, like "flatten_target" inherent to olso.policy
16:53:14 <kmalloc> opt-in so we don't break anyone
16:53:22 <kmalloc> but it would be a nice-to-have
16:54:02 <ayoung> kmalloc, yeah, we need to move some of the mechanisms we build for the CLI into toolijng for others to use.  That one is the obvious one, aloth, for servicees, they tend to use context, which does that for you...sort of
16:54:27 <ayoung> aloth.>altho
16:54:55 <lbragstad> unrelated: does simo work at red hat?
16:54:58 <kmalloc> yes.
16:55:00 <ayoung> lbragstad, yep
16:55:12 <ayoung> lbragstad, still in my old group, that does IdM etc
16:55:13 <kmalloc> ayoung: if you can get another pass by simo on the jwt thing
16:55:22 <ayoung> happy to do so
16:55:24 <kmalloc> thnx
16:55:26 <lbragstad> timing isn't ideally, but i agree with cmurphy that it would be nice to get their eyes on the jwt thing one more time
16:55:49 <kmalloc> i have one more review that i want to raise up as a potential thing
16:55:52 <lbragstad> thanks ayoung and kmalloc
16:55:54 <kmalloc> for folks to look at
16:56:00 <kmalloc> #link https://review.openstack.org/#/c/613681/
16:56:12 <ayoung> So... will JWT give us a way to do PKI type signing?
16:56:19 <kmalloc> that requires some work, but i want some extra eyes to determine if a None header is within WSGI spec
16:56:29 <kmalloc> the rest of the code should be "ok" otherwise.
16:56:33 <ayoung> specifically, I want one keystone to be able to sign a token, and for other services to be able to validate without forging them
16:56:51 <kmalloc> ayoung: eventually. JOSE with asym encryption/validation
16:57:06 <kmalloc> but that is a few steps outside of JWT addition
16:57:10 <cmurphy> erm that's for other keystones to validate them, not other non-keystone services
16:57:10 <kmalloc> to keystone
16:57:20 <cmurphy> right?
16:57:22 <kmalloc> it could be possible
16:57:22 <lbragstad> yeah - that is noted specifically as an advantage of jwt
16:57:26 <ayoung> cmurphy, anyojne should be able to validate....
16:57:42 <kmalloc> 3 minutes, time check
16:57:54 <ayoung> the only reason we send them back to keystone is because of the Fernet spec.  PKI tokens were validated in the services
16:58:09 * kmalloc ducks out, food.
16:58:13 <lbragstad> the major hurdle is that services need roles
16:58:18 <kmalloc> be back in -keystone post meeting.
16:58:19 <lbragstad> in order to do rbac
16:58:28 <lbragstad> and we don't include unbound things in the token payload
16:58:52 <ayoung> cmurphy, and, one Keystone may not be a peer to the other keystone.  I was brainstorming some of this for the edge talk
16:59:14 * ayoung needs to go find the slip of paper he was scribbling on with all these ideas
16:59:28 <lbragstad> we can take this to -keystone later, too
16:59:33 <lbragstad> thanks for coming, all
16:59:55 <lbragstad> #endmeeting