16:00:03 <lbragstad> #startmeeting keystone
16:00:04 <openstack> Meeting started Tue May 15 16:00:03 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:08 <openstack> The meeting name has been set to 'keystone'
16:00:12 <lbragstad> ping ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy, sonuk
16:00:18 <knikolla> o/
16:00:19 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:23 <lbragstad> agenda ^
16:00:42 <wxy|> o/
16:01:03 <hrybacki> o/
16:01:34 <ayoung> He, Ho.  Lets go!
16:01:58 <gagehugo> o/
16:02:45 <lbragstad> we'll give folks another minute to join
16:03:07 <kmalloc> o/
16:03:07 <jgrassler> o/
16:04:16 <lbragstad> ok - let's get started
16:04:19 <lbragstad> #topic specifications
16:04:36 <lbragstad> reminder that our next project deadline is milestone 2, which is specification freeze
16:04:51 <lbragstad> we have a couple specs left that are looking good, and need reviews
16:04:55 <lbragstad> #link https://review.openstack.org/#/c/540803/
16:04:57 <lamt> o/
16:05:16 <lbragstad> ^ is the unified limits specification and it details the first hierarchical enforcement model we'll be targeting
16:05:16 <hrybacki> ^^ looks like it's in solid shape
16:05:29 <lbragstad> thanks wxy| for keeping that updated
16:05:53 <lbragstad> an earlier iteration of that proposal actually got a +1 from tim bell
16:05:59 <cmurphy> o/
16:06:07 <kmalloc> nice.
16:06:12 <lbragstad> it would be cool to get his sign off again
16:06:21 <lbragstad> and possible yankcrime or johnthetubaguy
16:06:25 <kmalloc> good to hear that the Cern folks are happy with the general direction, and ++ his +1 again would be good.
16:06:25 <lbragstad> possibly*
16:07:01 <lbragstad> next: default roles
16:07:10 <lbragstad> #link https://review.openstack.org/#/c/566377/
16:07:30 <lbragstad> that one is super close too
16:07:41 <hrybacki> aye, I commented on your comment lbragstad
16:07:46 <hrybacki> AFIAC it's g2g
16:08:01 <lbragstad> cool - i'll revisit that after the meeting for sure
16:08:22 <hrybacki> thanks lbragstad
16:08:23 <lbragstad> #link https://review.openstack.org/#/c/464678/ is also shaping up
16:08:56 <hrybacki> aye, still needs to be moved into the stein specs folder
16:09:13 <kmalloc> cool, i'll get eyes on it too post meeting
16:09:21 <lbragstad> if anyone has time to review those, that would be fantastic
16:09:38 <lbragstad> does anyone else have anything for specifications/
16:10:02 <hrybacki> lbragstad: is it feasible to land the default roles spec before Monday?
16:10:19 <hrybacki> asking for a friend
16:10:36 <lbragstad> afaict - i don't have any objections and my comments have been addressed
16:10:51 <lbragstad> pending a look this afternoon - i'll likely put my +2 on it
16:10:54 <hrybacki> ack ack
16:11:03 <knikolla> I’ll review also
16:11:10 <hrybacki> thanks knikolla
16:11:12 <lbragstad> thanks knikolla
16:11:33 <lbragstad> anything else specification wise?
16:11:51 <knikolla> Jwt?
16:12:28 <lbragstad> looks like we got some feedback from someone who is familiar with k8s
16:12:29 <lbragstad> #link https://review.openstack.org/#/c/541903/
16:13:04 <lbragstad> but - other than that, it hasn't really been reviewed in the last month or so
16:13:25 <kmalloc> oh that is fantastic (the feedback)
16:13:37 <lbragstad> we still need to figure out how we would incorporate that support, and how opinionated we would be
16:14:20 <knikolla> Should we discuss this at the summit?
16:14:32 <lbragstad> we can
16:14:42 <lbragstad> likely going to be isolated to hallway tracks
16:14:49 <lbragstad> we don't have a formal session for it
16:15:06 <kmalloc> i think we should. i think we need to be very opinionated, but i want to be sure we are flexible enough get k8s cross support as described
16:15:15 <kmalloc> hallway track should be fine
16:15:41 <lbragstad> just a warning, we'll need to be on top of documenting what we come up with and reviewing it right away
16:15:44 <kmalloc> we can also focus on scafolding and push the opinionated discussion to the next PTG if we can't come to a conclusion here
16:15:47 <lbragstad> if we still plan to target this to rocky
16:16:06 <knikolla> i'd really like to see this for rocky.
16:16:43 <lbragstad> let's make a point to discuss it then
16:17:21 <knikolla> i can take more ownership pushing the discussion since i have almost nothing on my keystone plate.
16:17:32 <lbragstad> knikolla: that'd be great
16:17:54 <lbragstad> a word about the technical discussions on this stuff
16:18:19 <lbragstad> i'm a slow reader, but there is a lot of material about this stuff
16:18:51 <lbragstad> either within the k8s community, the jwt/jwe/jws RFCs, etc..
16:19:53 <lbragstad> if anyone is looking to participate in those discussion, that might make for some fruitful reading if you're on a plane
16:20:39 <lbragstad> only saying this because i vastly underestimated the amount of time needed to get up to speed on the stuff
16:20:55 <ayoung> I've got some K8S familiarity
16:21:16 <lbragstad> are you familiar with how the token system within k8s works?
16:21:38 <lbragstad> (not that we need to get into the details now)
16:21:49 <ayoung> yeah, I can take that one
16:21:52 <lbragstad> but that knowledge will be helpful if we plan to discuss this next week
16:22:02 <lbragstad> ayoung: you want to work with knikolla on some of that then?
16:22:14 <ayoung> Sure
16:22:19 <lbragstad> thanks
16:22:23 <kmalloc> i'll ride along w/ ayoung
16:22:31 <lbragstad> oh - good deal
16:22:32 <kmalloc> just so we have a couple folks familiar
16:22:47 <ayoung> K8S is important to my new life, too
16:22:55 <kmalloc> besides, i'm poking at k8s so good to have knowledge
16:23:03 <lbragstad> sounds like a productive car ride
16:23:07 <hrybacki> I'm envisioning kmalloc reading aloud in a melodic voice to Adam as he drives
16:23:08 <lbragstad> anything else specification wise?
16:23:12 <kmalloc> LOL
16:23:24 <kmalloc> I'd just put him to sleep and then that is bad.
16:23:25 <hrybacki> autotunkens
16:23:56 <ayoung> Probably other way around.  Kar belongs to Kmalloc  and I am the one tending to sing
16:24:15 <kmalloc> LOL
16:24:18 <hrybacki> lol
16:24:24 <hrybacki> I think we're good on specs lbragstad :)
16:24:31 <lbragstad> cool
16:24:35 <lbragstad> #topic community goals
16:25:00 <lbragstad> we don't have anything to do with the mox community goal this release
16:25:06 <lbragstad> but we're in an interesting position with the other
16:25:20 <kmalloc> yay, we're out from under Mox!
16:25:25 <kmalloc> [we have been for a while]
16:25:30 <lbragstad> jroll: and knikolla brought it up on the mailing list
16:25:32 <lbragstad> #link #link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130467.html
16:26:04 <lbragstad> i attmpted to knock this out yesterday, but it was a little more involved than i was expecting
16:26:31 <lbragstad> i wanted to run the options by the group and hopefully figure out what the best way forward is
16:26:53 <lbragstad> #link https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
16:26:58 <lbragstad> ^ that's the community goal
16:27:04 <kmalloc> lbragstad: between the two of us where we're digging around we can probably make that happen
16:27:17 <kmalloc> (me with flask stuff and you with the config bits)
16:27:43 <lbragstad> right - we have some refactoring to do in that area
16:28:12 <kmalloc> actually... we can consistently rely on etcd existing, right?
16:28:20 <kmalloc> in an openstack deployment, right?
16:28:51 <kmalloc> can we lean on something like that for toggling some config overrides?
16:29:01 <kmalloc> etcd/zk/consul/something
16:29:18 <lbragstad> i know it's a base service
16:29:24 <lbragstad> but that's about all i know
16:29:27 <kmalloc> lets see how reliable that is.
16:29:41 <kmalloc> it might meet our needs for debug [make it a ks-manage commange to toggle]
16:29:54 <kmalloc> i have some other ideas
16:29:58 <kmalloc> if that doesn't work
16:30:02 <lbragstad> like what?
16:30:31 <kmalloc> looking into the socket communication, etc like we touched on yesterday
16:30:46 <kmalloc> but i'll need to see how the wsgi-runners will work and if the parent process can listen.
16:31:15 <lbragstad> ^ that's the point where the wheels fell off yesterday when i was thinking about this
16:31:34 <kmalloc> but we have ot be super careful because a number of our configs cannot be changed without a hard restart, due to how the managers/drivers are loaded
16:31:55 <lbragstad> yeah
16:31:57 <kmalloc> so i *think* we need to slowly edge into mutable configs, i think debug is 100% a good place to start.
16:32:19 <lbragstad> so far, debug is the only concrete example in the community goal
16:32:24 <kmalloc> i am ok-ish leaning on an external service.
16:32:33 <kmalloc> if it's reliably in place
16:33:10 <kmalloc> i'll take a closer look at uwsgi and mod_wsgi to see how we can handle reload of config at runtime, mod_wsgi might be an apache reconfigure
16:33:20 <kmalloc> and the _only_ real option, short of etcd.
16:33:27 <lbragstad> sure
16:33:46 <kmalloc> but i *think* we can issue some interesting things to uwsgi (almost certain, or we could provide an extension to it)
16:33:51 <lbragstad> otherwise - we're going to be listening for a specific event and just doing a re-init of the logger as far as i can tell
16:33:59 <kmalloc> and gunicorn would be similar to uwsgi, once we can use it [if we decide to test it]
16:34:33 <kmalloc> lbragstad: i don't think we need to even re-init the logger. we might be able to just override the config, most of our debug just checks for debug in config.
16:34:57 <lbragstad> oh - it's reloaded at runtime?
16:35:14 <kmalloc> no, if we set the loglevel to DEBUG we are just skipping the noop check
16:35:30 <kmalloc> we are already debug logging, but python logger is just not emitting anything because level is > DEBUG
16:35:38 <kmalloc> s/emitting/doing work/
16:35:54 <kmalloc> and in some cases we have a if debug: logic check
16:36:15 <kmalloc> so we may not need to re-init the logger we may just need to set the log-level on the logger object.
16:36:16 <lbragstad> oh - sure
16:36:31 <kmalloc> and ensure our oslo.config object has the right value
16:36:58 <lbragstad> so - every other project is going to be using mutable configs it sounds lie
16:37:00 <lbragstad> like*
16:37:11 <lbragstad> which means the "event" is changing the configuration option
16:37:40 <lbragstad> ideally it would be nice to maintain that experience instead of coming up with a different event to signal this off of
16:37:49 <kmalloc> i can see how inotify works for multiple listeners.
16:38:08 <hrybacki> lbragstad+1
16:38:11 <kmalloc> and ++
16:38:18 <kmalloc> but if we can't, lets make it as easy as possible
16:38:38 <kmalloc> let me look at the mutable config mechanism(s) and see how we can read the event[s] with our wsgi containers
16:38:48 <lbragstad> i only bring that up because picking up notifications off other files that aren't configuration files was another possible solution
16:38:57 <lbragstad> cool - thanks kmalloc
16:43:01 <lbragstad> does anyone else have questions on the gaol?
16:43:04 <lbragstad> goal*?
16:44:23 <lbragstad> #topic open discussion
16:44:53 * hrybacki has nothing
16:46:12 <lbragstad> alrighty - i appreciate everyone's time
16:46:19 <lbragstad> reminder that office hours will be starting in about 15 minutes
16:46:22 <hrybacki> likewise lbragstad
16:46:28 <lbragstad> thanks folks
16:46:35 <hrybacki> o/
16:46:40 <lbragstad> #endmeeting