16:00:10 <lbragstad> #startmeeting keystone
16:00:10 <openstack> Meeting started Tue Oct  9 16:00:10 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'keystone'
16:00:15 <cmurphy> o/
16:00:17 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:21 * cmurphy partly in another meeting
16:00:22 <lbragstad> agenda ^
16:00:37 <gagehugo> o.
16:00:38 <lbragstad> i appreciate you running the meeting last week cmurphy
16:00:41 <gagehugo> o/
16:00:48 <cmurphy> no problem
16:01:04 <cmurphy> glad to have you back lbragstad :)
16:01:16 <lbragstad> :)
16:01:16 <hrybacki> o/
16:01:42 * cmurphy makes note to double check lbragstad's code for sleep deprivation errors
16:02:08 <lbragstad> psh... i have sleep deprivation errors in my code when I get a full 7 hours
16:02:10 <wxy|> o/
16:02:13 <cmurphy> lol
16:02:37 <hrybacki> hes trained for this
16:03:18 <lbragstad> i've prepared myself by making sure there are errors in my code that make it seem like i'm always sleep deprived
16:03:54 <lbragstad> which sounds like a weird method of reverse psychology
16:04:34 <hrybacki> hes genius
16:04:35 <kmalloc> o/
16:04:59 <kmalloc> heheh
16:05:06 <kmalloc> well played lbragstad well played
16:05:15 <cmurphy> explains a lot really ;)
16:05:27 <lbragstad> lol
16:05:31 <kmalloc> lbragstad: so you're saying i should start introducing sleep deprivation errors in my code now... for when kid comes next year for me?
16:05:32 <kmalloc> ;)
16:05:43 <lbragstad> yes... start early
16:06:08 <lbragstad> alrighty
16:06:13 <lbragstad> #topic specification reviews
16:06:14 <kmalloc> cmurphy: sorry, you're going to have to deal with my code being crummier than usual soon ^ you heard lbragstad tell me it was a good idea
16:06:29 <lbragstad> #link https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open+NOT+reviewedby:self
16:07:03 <lbragstad> specification proposal freeze is the 26th - which i'm sure everyone is aware of
16:07:14 <lbragstad> #link https://releases.openstack.org/stein/schedule.html
16:07:39 <lbragstad> does anyone know of specifications that we've talked about that are _not_ currently proposed?
16:08:11 <lbragstad> #https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open all open keystone-spec reviews
16:08:51 * lbragstad wonders if ayoung is going to be around?
16:09:18 <cmurphy> might need a reminder
16:09:28 <cmurphy> oh he's not online
16:09:47 <lbragstad> i noticed he had a bunch of things proposed
16:10:02 <lbragstad> some of which were discussed last week during the meeting
16:10:19 <lbragstad> and some that were back logged specs from a long time ago
16:10:51 <kmalloc> the JWT spec probably need some serious eyes to make sure Simo's concerns are covered
16:11:01 <kmalloc> otherwise it shouldn't be too hard to get lined up to land
16:11:12 <lbragstad> i attempted to update, should be ready for eyes
16:11:22 <kmalloc> yeah
16:11:47 <lbragstad> since simo isn't able to review directly, i'd like to wait for his signoff via whatever means necessary
16:12:13 <kmalloc> the aud bits are the only real concern
16:12:19 <kmalloc> the rest we weren't too far away from.
16:12:27 <lbragstad> well - that and the algorithm i think
16:12:39 <lbragstad> but i updated that already
16:12:52 <kmalloc> at the PTG we discussed the ES256
16:13:31 <kmalloc> so i am not worried as long as we default to the safe algo
16:13:36 <kmalloc> and support pools of algos.
16:14:34 <cmurphy> i don't recall supporting pools being the plan for the first iteration
16:14:54 <lbragstad> by pool do we mean fernet and jwt?
16:14:58 <kmalloc> no, as long as we don't back ourselves into a corner where we can't support it we're good
16:15:02 <lbragstad> or is the pool specific to jwt?
16:15:13 <kmalloc> lbragstad: no in JWT allowing for multiple crypto algorithms
16:15:21 <cmurphy> kmalloc: ++
16:15:29 <kmalloc> so in the case of a compromise/failure of one, we can pivot to another with config
16:15:40 <kmalloc> it would work like bcrypt/scrypt for password hashing
16:15:59 <lbragstad> pivit from one jwt mechanism to another jwt mechanism you mean?
16:16:06 <lbragstad> pivot*
16:16:30 <kmalloc> yes, but it allows for using multiple crypto forms in the same token
16:16:55 <lbragstad> ack
16:16:59 <lbragstad> ok - that makes sense
16:17:47 <lbragstad> does everyone feel pretty comfortable carrying the rest of the jwt discussion in review?
16:18:20 <cmurphy> +1
16:18:55 <gagehugo> sure
16:19:04 <lbragstad> does anyone have a specific issue or point they'd like to raise about specs currently in review?
16:20:27 <lbragstad> ok - moving on
16:20:37 <lbragstad> #topic oslo.messaging 9.0.0 breaks keystone
16:20:50 <lbragstad> in case you missed it
16:20:51 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2018-October/135544.html
16:21:47 <lbragstad> fwiw - version 9.0.1 should fix things for keystone
16:22:04 <lbragstad> but the more concerning bit is that we're relying on internal implementation details of oslo.messaging in keystone tests
16:22:37 <lbragstad> #link https://review.openstack.org/#/c/609031/1
16:23:00 <lbragstad> i have a note to investigate those tests and see if we still need them or if they need to be rewritten somehow
16:23:20 <lbragstad> if you're interested in picking through some of those things, just let me know
16:23:43 <lbragstad> any questions on this?
16:23:44 <kmalloc> tl;dr we should push ourselves up a layer and stop mocking internals of a lib.
16:24:02 <kmalloc> if we need to validate what is sent down the wire, check we sent sane stuff into oslo.messaging
16:24:17 <kmalloc> if there is a good fixture for o.m to do what we do, that is also an option
16:24:44 <lbragstad> dhellmann was saying they could investigate adding something like that if we actually need it as a test fixture, too
16:24:52 <lbragstad> which is a nice option to have if we need it
16:25:12 <kmalloc> i don't think we really need that
16:25:21 <kmalloc> but, i would use it if it existed
16:25:33 <lbragstad> yeah
16:25:36 <kmalloc> checking we are sending correct info into oslo.messaging is all we need to do
16:25:52 <lbragstad> which we should be able to do by mocking the public interface
16:26:17 <dhellmann> lbragstad : I was suggesting that if you need it, we'd be happy to have you add it :-)
16:26:22 <dhellmann> and we can probably find someone to help
16:26:40 <lbragstad> of course
16:28:03 <lbragstad> i plan to have an answer or plan on what to do by EOD
16:28:13 <lbragstad> any other questions on this?
16:28:55 <lbragstad> #topic reviews
16:29:03 <lbragstad> does anyone have stuck reviews they want to discuss?
16:30:32 <lbragstad> #topic open discussion
16:30:37 <lbragstad> floor is open
16:31:36 <kmalloc> flaskification auth conversion and followup need eyes
16:31:45 * lbragstad makes a note to review those
16:31:47 <kmalloc> the users stuff will be posted today
16:32:09 <kmalloc> down to ~50 failing tests
16:32:40 <gagehugo> yeah I'll look at the auth stuff this afternoon
16:33:16 <kmalloc> note: the json format token rendering is staying in keystone.common because RBACEnforcer has a dependency on the json output/dict format
16:33:39 <cmurphy> that's okay with me for now
16:33:39 <kmalloc> since common code relies on it, it is staying in keystone.common instead of moving to keystone.token or keystone.api
16:33:51 <kmalloc> cmurphy: yeah, once we fix that dep, it should totally move to keystone.api
16:33:57 <lbragstad> cool
16:34:01 <lbragstad> that works
16:34:18 <kmalloc> there is one minor behavior change
16:34:41 <kmalloc> and that is that request_json_body will pass over a utf-8 encoding issue that would previously generate a 500 in webob
16:34:55 <kmalloc> if it made it past the json.loads() in the json-body middleware
16:36:19 <cmurphy> i'm mostly okay with that too i just wanted to raise it in case it was a bigger deal that i thought
16:36:26 <kmalloc> yep, good catch :)
16:37:10 <lbragstad> in other news, it looks like we have all three outstanding community goals in progress
16:37:18 <kmalloc> once users, projects, auth are ported we have ec2token(auth) and s3
16:37:27 <kmalloc> at that point we are done with the core of flaskification
16:37:51 <kmalloc> the last cleanup is to merge down the middleware in keystone and drop all webob dependencies
16:38:00 <kmalloc> it will be massive code removal at that point (yay)
16:39:32 <kmalloc> i just want to thank everyone for putting up with massive code restructuring to make flask happen
16:39:52 <lbragstad> thanks for driving the work :)
16:40:15 <gagehugo> ++
16:42:42 <lbragstad> fwiw - knikolla has a review up for mutable configuration
16:43:17 <lbragstad> https://review.openstack.org/#/c/585417/
16:43:21 <lbragstad> #link https://review.openstack.org/#/c/585417/
16:43:41 <lbragstad> since the flask work is coming to a head, we can start taking a closer look at that
16:43:57 <lbragstad> and afaik we've merged all the python3-first patches
16:44:21 <lbragstad> but we might need to double check the criteria to make sure we've completed all of that stuff
16:44:23 <cmurphy> we still have work to do on that one
16:44:35 <cmurphy> we need to make sure we're running python3 functional tests everywhere
16:44:43 <lbragstad> ++
16:44:48 * cmurphy will work on that
16:44:58 <lbragstad> sweet - thanks cmurphy
16:45:18 <lbragstad> are you expecting that to be a large change?
16:45:26 <cmurphy> lbragstad: no not at all
16:45:28 <lbragstad> or is it just flipping a few bits in zuul configs?
16:45:37 <cmurphy> just a couple of copy and paste in the zuul config
16:45:41 <lbragstad> awesome
16:46:23 <lbragstad> i have a patch up for upgrade checkers
16:46:26 <lbragstad> #link https://review.openstack.org/#/c/608785/
16:46:38 <lbragstad> it's pretty basic, but it lays down the plumbing for us
16:47:06 <lbragstad> i think we're waiting on a new release of oslo.upgradecheck, which should be landing soon
16:48:19 <lbragstad> i think that's about all i had
16:48:34 <lbragstad> does anyone have anything they'd like to raise before we call it?
16:49:34 <lbragstad> thanks for coming
16:49:38 <lbragstad> #endmeeting