16:00:10 <cmurphy> #startmeeting keystone
16:00:11 <openstack> Meeting started Tue Sep 10 16:00:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:14 <openstack> The meeting name has been set to 'keystone'
16:00:17 * kmalloc pours coffee
16:00:29 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:01:00 <vishakha> o/
16:01:27 <bnemec> o/
16:01:31 <ayoung> o/
16:01:52 <lbragstad> o/
16:01:53 <gagehugo> o/
16:05:11 <cmurphy> #topic announcements
16:05:32 <cmurphy> okay first announcement:
16:05:33 <knikolla> o/
16:05:56 <cmurphy> thanks ayoung for joining - ayoung has let me know that he's stepping back from the keystone core team
16:06:05 <lbragstad> :(
16:06:09 <cmurphy> i want to sincerely thank ayoung for all the years he has put into this project, keystone would not be what it is today without him
16:06:20 <ayoung> Thanks.
16:06:34 * lbragstad remembers ayoung helping him get onboarded to keystone back in 2013
16:06:49 <lbragstad> thanks for all your contributions ayoung
16:06:49 <knikolla> I’ll buy you a beer Adam when I’m back in Boston.
16:07:01 <ayoung> This is an acknowledgement that I no longer have my finger on the pulse of the project.  I'll be around, and if anytthing changes, I can be back up to speed quickly
16:08:10 <cmurphy> i'm sure we'll still pester you with questions
16:08:42 <ayoung> :)
16:10:58 <ayoung> I'm done.
16:11:51 <gyee> ayoung, thanks for everything! I am sure not just Keystone, everyone in the OpenStack community have one of those "I remember ayoung helped me out" stories.
16:12:58 <gyee> so what are we going to do with those #FIXME(ayound) thingies in the code? :-)
16:13:19 <cmurphy> haha
16:13:20 <ayoung> Fix them
16:13:43 <cmurphy> second announcement, now that the election is over i wanted to mention that at the moment i am not planning on running for a third term as ptl, unless there is really no other option, so if anyone has an inkling that they might want to step up and fill the role please let me know and i'll be happy to answer questions
16:14:03 <ayoung> [ayoung@ayoungP40 keystone]$ grep -rni ayoung keystone
16:14:03 <ayoung> keystone/assignment/core.py:1330:    # TODO(ayoung): Add notification
16:14:03 <ayoung> keystone/auth/core.py:302:            # TODO(ayoung): when trusts support domains, fill in domain data
16:14:03 <ayoung> keystone/identity/backends/ldap/core.py:435:                # NOTE(ayoung): LDAP_SCOPE is used here instead of hard-
16:14:04 <ayoung> keystone/tests/unit/test_v3_protection.py:226:        # TODO(henry-nash, ayoung): It would be good to expand this
16:14:07 <ayoung> keystone/tests/unit/test_v3_auth.py:3811:        # NOTE(ayoung): not deleting token3, as it should be deleted
16:14:10 <ayoung> Heh
16:14:32 <lbragstad> thanks for the heads up cmurphy
16:14:45 <cmurphy> definitely not planning on going anywhere though
16:14:48 <cmurphy> so don't worry about that
16:15:00 <kmalloc> i'm not worried about another great PTL rising up to the challenge. we have great people in the community
16:15:43 <kmalloc> ayoung: soo... about LDAP integration in keystone </wink wink> :P
16:17:04 <ayoung> remove it
16:17:18 <gyee> LOL
16:18:08 <cmurphy> let's move on, agenda is not small today
16:18:38 <cmurphy> #topic reviews
16:18:48 <cmurphy> lbragstad: you mentioned the ksa one on the agenda
16:19:09 <lbragstad> yep - i'm just curious about following up this discussion
16:19:16 <lbragstad> since there was discussion on it a while ago
16:19:31 <lbragstad> i address some of the concerns, but wanted to give folks a chances to give it another look
16:19:38 <lbragstad> or raise any issues they have with it
16:20:22 <kmalloc> the retry bits?
16:20:27 <lbragstad> yeah
16:20:36 <kmalloc> i don't like it. i think the alternative almost requires a ksa2
16:21:02 <lbragstad> the alternative?
16:21:15 <kmalloc> adding in explicit retry settings for all auth-path
16:21:26 <kmalloc> which impacts get_endpoint, get_auth, etc
16:21:43 <kmalloc> or explicit retry options for each auth path method.
16:21:51 <kmalloc> which i like less than global retry setting
16:22:00 <kmalloc> s/global/session/
16:22:07 <lbragstad> oh - i think the current approach reuses the session object
16:22:13 <kmalloc> yeah it does
16:22:24 <kmalloc> which makes it the least obnoxious option for end users to consume
16:22:47 <kmalloc> short of breaking the contract and making things cleaner in how KeystoneAuth processes auth path. which would require ksa2
16:23:10 <kmalloc> so... tl;dr, i don't like it but i don't have a good alternative if we need this retry logic in the session
16:23:34 <kmalloc> auth is "special" (unfortunately) and we'll probably have subsequent questions in the future on retry's on auth
16:23:39 <kmalloc> so... we can land it as is
16:24:01 <lbragstad> sounds good - we can continue to discuss offline, too
16:24:14 <lbragstad> i wanted to raise awareness
16:24:40 <lbragstad> that's it from me cmurphy
16:24:48 <cmurphy> thanks lbragstad
16:24:52 <lbragstad> np
16:25:13 <cmurphy> i want to specifically beg for reviews on the remainder of the stack starting at https://review.opendev.org/668238
16:25:26 <kmalloc> cmurphy: just +2'd that one
16:25:34 <cmurphy> thanks kmalloc
16:25:35 <kmalloc> and i think i have +2 on the rest of the stack
16:25:44 <cmurphy> i have a talk on it and would be super sad if it didn't make it in
16:25:50 <lbragstad> i'm just reading your response to my question now
16:26:07 <lbragstad> so - access rules are reusable across users today, yeah?
16:26:21 <cmurphy> lbragstad: no, access rules are owned by a user
16:26:36 <cmurphy> a user can reuse them in different app creds though
16:26:43 <lbragstad> "An access rule record isn't specific to a particular app cred, they are only specific to a user, so they won't be duplicated except when different users create the same ones."
16:27:01 <lbragstad> so - if we both create app creds and we both specify  the same access rule
16:27:15 <lbragstad> there are going to be two access rules persisted in the backend even though they're the same?
16:27:25 <cmurphy> yes because we have a user_id in the model
16:27:32 <lbragstad> ok - got it
16:27:58 <lbragstad> in the future we could refactor and migrate to share app creds, it sounds like
16:28:06 <cmurphy> yes i think so
16:28:25 <lbragstad> awesome - sorry, i'm not trying to pre-optimize
16:28:32 <cmurphy> :)
16:28:34 <lbragstad> just something that cross my mind when i was looking at the object model
16:29:25 <cmurphy> besides that i made a list of things we're aiming to land this week
16:29:35 <cmurphy> #link https://etherpad.openstack.org/p/keystone-train-feature-freeze-todo feature freeze reviews
16:30:23 <cmurphy> knikolla: i didn't include the expiring group work, it didn't look ready and isn't passing ci
16:30:41 <cmurphy> so i think we need to let it slip unless i've missed something?
16:31:33 <knikolla> Yeah, I’m sorry. Had to take a step back and focus on mental health.
16:31:53 <cmurphy> i support that
16:32:03 <knikolla> I’ll be on vacation through the 29th
16:32:34 <cmurphy> nice, enjoy and thanks for the headsup
16:32:41 <lbragstad> ++
16:33:03 <vishakha> knikolla enjoy
16:33:16 <knikolla> Thank you
16:33:32 <kmalloc> on the topic of vacation
16:33:34 <kmalloc> FYI I'll be starting vacation around sept. 30... and then uhm. i'll be dealing with new kid
16:33:54 <kmalloc> so. yeah.
16:34:18 <cmurphy> kmalloc: just come back with baby pictures
16:34:35 <kmalloc> hehe
16:37:20 <cmurphy> on the topic of reviews, we bumped the timeouts for most of the tox jobs so that we could try to get more throughput (missed one https://review.opendev.org/681161 it's going through now) but i suggest that once all the policy changes are merged that we merge https://review.opendev.org/680788 which is a slightly more robust hack to workaround the issue
16:37:47 <lbragstad> i like that idea
16:38:01 <cmurphy> and any help reviewing everything in https://etherpad.openstack.org/p/keystone-train-feature-freeze-todo is much appreciated
16:39:14 <cmurphy> anything else on the reviews topic?
16:39:41 <lbragstad> i appreciate folks picking up the slack on the policy/system-scope/default roles work
16:40:00 <lbragstad> i walked through most of the outstanding review last night and they look great
16:40:00 <cmurphy> you laid solid groundwork to follow
16:40:08 <cmurphy> thanks for all the reviews
16:40:18 <lbragstad> it's the least i could do
16:41:33 <cmurphy> #topic forum planning
16:41:47 <cmurphy> #link https://etherpad.openstack.org/p/PVG-keystone-forum
16:41:59 <cmurphy> i split out the forum etherpad
16:42:08 <cmurphy> I know most people aren't planning on being there
16:42:30 <lbragstad> is the plan to cover things there and post recaps?
16:42:46 <lbragstad> or are you planning on attempting to host a virtual presence of some kind?
16:42:55 <cmurphy> i will certainly be taking notes and posting recaps
16:43:11 <cmurphy> i definitely do not want to try to manage virtual attendance
16:43:16 <cmurphy> in china
16:43:21 * lbragstad nods
16:43:50 <lbragstad> timezones are going to make that really tough anyway
16:44:10 <lbragstad> (let along trying to find a VC solution)
16:44:14 <lbragstad> alone*
16:44:37 <cmurphy> there are only two topics proposed, personally i don't need to propose other topics - i think we're moreorless set wrt app creds and i think federation topics can be covered in the virtual ptg if we need to
16:45:19 <cmurphy> but i'm open to moderating more sessions if people think there are other things worth proposing
16:45:23 <vishakha> I would also add alembic migrations for PTG
16:46:19 <cmurphy> vishakha: that was my next topic, go ahead and add it to the ptg etherpad https://etherpad.openstack.org/p/keystone-shanghai-ptg
16:46:43 <vishakha> :)
16:46:56 <cmurphy> bnemec: how do you feel about proposing/moderating the oslo.limit forum session?
16:47:36 <bnemec> Sure, I can do that.
16:47:40 * lbragstad nods vigorously
16:47:53 <bnemec> I'm assuming that means lbragstad won't be there. :-/
16:48:01 <cmurphy> lbragstad: did you figure out whether you would make it?
16:48:02 <lbragstad> tbd
16:48:11 <lbragstad> i'll know by eow
16:48:18 <cmurphy> mmk
16:48:18 <lbragstad> er - thursday actually
16:48:32 <cmurphy> cool
16:49:06 <cmurphy> i'll plan on proposing a session on policy
16:49:17 <cmurphy> lbragstad: you can co-moderate one or both if you end up making it :)
16:49:26 <bnemec> +1
16:49:50 <lbragstad> sweet - if that means take notes, i'm all in
16:49:54 <lbragstad> ;)
16:49:57 <cmurphy> lol
16:50:12 <bnemec> If it means I _don't_ have to take notes, +1000. :-)
16:50:16 <cmurphy> ++
16:50:41 <lbragstad> moderating while attempting to take notes is a pain
16:52:09 <cmurphy> last topic, few minutes left
16:52:14 <cmurphy> #topic ptg planning
16:52:19 <cmurphy> #link https://etherpad.openstack.org/p/keystone-shanghai-ptg
16:52:31 <cmurphy> we discussed doing a pre- and post- virtual ptg
16:52:59 <cmurphy> i wrote up a straw man schedule but not really sure how many hours/days to take
16:53:05 <cmurphy> depends on how many topics there are to discuss
16:53:09 <lbragstad> so - the virtual ptg is going to be similar to the one we did for Train, right?
16:53:21 <cmurphy> lbragstad: you mean the midcycle?
16:53:30 <lbragstad> yeah - midcycle
16:53:37 <cmurphy> yeah that's pretty much what i had in mind
16:53:42 <lbragstad> cool
16:53:57 <cmurphy> any other ideas for how to organize it?
16:55:34 <cmurphy> any comments on the straw man schedule or any other topic ideas?
16:56:11 * lbragstad wonders what spectroscope is
16:56:25 <cmurphy> lbragstad: the proxy idp
16:56:32 <lbragstad> oooooo
16:56:41 <lbragstad> i didn't realize it had a name
16:57:33 <cmurphy> if we keep it a short-ish session (2-3 hours) then i would probably suggest we hold it over the normal meeting time, one week before and one week after the summit
16:58:03 <cmurphy> if we decide we need more time i'll start a scheduling poll
16:58:53 <cmurphy> #topic open discussion
16:59:07 <cmurphy> anything else to bring up in the next two minutes?
17:00:17 <cmurphy> okay thanks everyone
17:00:18 <cmurphy> #endmeeting