16:00:32 <cmurphy> #startmeeting keystone
16:00:33 <openstack> Meeting started Tue Jul  2 16:00:32 2019 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:36 <openstack> The meeting name has been set to 'keystone'
16:00:56 <vishakha> o/
16:01:09 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:01:56 <lbragstad> o/
16:03:50 <kmalloc> o/
16:04:51 <cmurphy> hmm holiday week i guess
16:05:34 * lbragstad is out after today
16:06:04 <cmurphy> #topic midcycle planning
16:06:05 <kmalloc> yeah holidays... :P
16:06:24 <cmurphy> reminder to fill out the scheduling poll and the topic brainstorm
16:06:33 <cmurphy> #link https://etherpad.openstack.org/p/keystone-train-midcycle-topics topics
16:06:38 <cmurphy> #link https://doodle.com/poll/wr7ct4uhpw82sysg scheduling poll
16:06:53 <cmurphy> i think everyone here did that so this is more for people reading the minutes :)
16:07:39 * gagehugo sneaks in
16:08:01 * cmurphy wonders if knikolla is around
16:09:15 <cmurphy> i wanted to take a few minutes to go over our open train specs but maybe that can wait till next week
16:09:41 <kmalloc> probably a good idea, based upon how few people are here.
16:09:55 <cmurphy> #topic open discussion
16:10:33 <kmalloc> quick update
16:10:47 <kmalloc> resource option code (sql migrations, etc) will be published soon.
16:10:55 <cmurphy> sweet
16:10:58 <kmalloc> should unblock immutable
16:11:10 <kmalloc> i'm working out how to handle the "rolling" upgrade ick.
16:11:22 <kmalloc> it's not going to be clean because of that.
16:11:35 <cmurphy> :/
16:11:36 <kmalloc> but ... ultimately, should be fine.
16:11:45 <kmalloc> having to read/write useroptions to two locations
16:11:48 <kmalloc> and deconflicting those.
16:11:54 <kmalloc> it's going to be ugly.
16:12:05 <kmalloc> but future resource options will be a LOT better
16:12:58 <cmurphy> yay
16:13:02 <kmalloc> fyi, i am going to be moving soonish.
16:13:10 <kmalloc> like... have to be moved by early september
16:13:33 <kmalloc> so there will be some gaps on my 100% availability (transit time)
16:13:47 <kmalloc> but i don't expect it to be too impactful overally
16:13:51 <kmalloc> overall*
16:14:01 <kmalloc> just more of a "hey, i might disappear for a day or two here and there"
16:14:05 <cmurphy> good to know
16:14:28 <kmalloc> stressful, yes, impactful no. but moving is ALWAYS stressful :P
16:14:43 <cmurphy> staying in the same timezone?
16:15:33 <kmalloc> we're looking at options, it'll be california, az, or staying in WA
16:15:48 <kmalloc> so, if it's AZ it'll be same timezone for 1/2 the year :P
16:15:55 <cmurphy> lol
16:16:05 <kmalloc> (until the PDT forever change happens on the west coast)
16:16:12 <bnemec> Timezones are almost as fun as moving. :-)
16:17:11 <kmalloc> if PDT always happens, then AZ and CA/WA/(i think)OR will always be the same Timezone.
16:17:11 <cmurphy> lbragstad: still want to go through your oslo.limit stack after this?
16:17:18 <kmalloc> which would be nice.
16:17:20 <lbragstad> yep - i can do that
16:17:53 <lbragstad> it looks like at least a couple people took a look at the open reviews
16:18:42 <cmurphy> yup
16:19:19 <cmurphy> if there's nothing else let's go ahead and close this meeting and continue in #openstack-keystone
16:19:33 <lbragstad> thanks cmurphy
16:20:06 <vishakha> Keyring is still blocking https://review.opendev.org/#/c/660609/
16:20:53 <vishakha> If anyone can help on it ?
16:23:27 <cmurphy> hmm i can try to figure it out, i might have given bad advice on ps17
16:23:52 <kmalloc> ugh keyring?
16:24:00 <kmalloc> can we just drop it
16:24:12 <cmurphy> maybe
16:24:15 <cmurphy> it's in ksc
16:24:19 <kmalloc> it's caused us a lot of problems overall
16:24:21 <cmurphy> idk what we use it for
16:24:37 <kmalloc> it was used for caching login info at somepoint
16:25:29 <kmalloc> is train the py3 only release?
16:25:31 <cmurphy> looks like it's still very used, probably easier to fix the requirements issue than to drop it
16:25:37 <cmurphy> kmalloc: no
16:25:46 <kmalloc> bah
16:25:48 <kmalloc> i was hoping
16:25:51 <lbragstad> i think we have to wait until U
16:25:59 <lbragstad> before we can start dropping py2 code
16:26:11 <bnemec> Yep
16:26:24 <kmalloc> it is used. but, really it's caused us tons of problems over the years
16:26:33 <kmalloc> it's a *terrible* python module to consume imo
16:26:49 <cmurphy> this doesn't have anything to do with the module itself, just a mismatch against g-r
16:27:27 <kmalloc> right, but the reason we have the mismatch is because it's not a great module. and we need different versions per python version
16:28:15 <bnemec> Ugh, this again. I take it we haven't found a more elegant solution to libraries that are dropping py2 support then.
16:28:26 <kmalloc> short of us dropping py2, no
16:28:36 <cmurphy> sphinx has the same problem
16:28:39 <kmalloc> we're kindof far behind the curve
16:30:12 <cmurphy> anyways vishakha i'll try to poke at it this afternoon
16:30:31 <vishakha> Thanks cmurphy
16:30:47 <cmurphy> anything else?
16:30:57 * cmurphy pauses
16:31:22 * lbragstad is good
16:31:37 <cmurphy> 5
16:31:39 <cmurphy> 4
16:31:41 <cmurphy> 3
16:31:43 <cmurphy> 2
16:31:45 <cmurphy> 1
16:31:47 <cmurphy> #endmeeting