16:00:01 <lbragstad> #startmeeting keystone
16:00:02 <openstack> Meeting started Tue Jul  9 16:00:01 2019 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'keystone'
16:00:09 <knikolla> o/
16:00:15 <cmurphy> o/
16:00:15 <vishakha> o/
16:00:33 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:37 <lbragstad> ^ agenda
16:00:44 <bnemec> o/
16:01:29 <lbragstad> we'll give folks another minute or two to jion
16:01:32 <lbragstad> join*
16:01:34 <gagehugo> o/
16:03:00 <lbragstad> #topic midcycle planning
16:03:14 <cmurphy> o/
16:03:42 <cmurphy> so the doodle poll results are in and we'll hold the midcycle monday/tuesday july 22/23 14:00-17:00 UTC
16:04:08 <cmurphy> I could still use help with agenda planning though, if folks could add +1s to topics they think are most worthwhile to discuss that would help
16:04:20 <cmurphy> #link https://etherpad.openstack.org/p/keystone-train-midcycle-topics
16:04:31 <gagehugo> cool
16:04:36 <lbragstad> #info virtual midcycle will take place Monday, July 22nd 14:00 - 17:00 and Tuesday, July 23rd 14:00 - 17:00 UTC
16:05:04 <lbragstad> cmurphy do you have a hard cut off for when you want the schedule built out?
16:05:46 <cmurphy> lbragstad: i'm hoping by the end of the week, but it's probably okay if it's a little fluid until week-of
16:05:56 <lbragstad> ok
16:06:45 <cmurphy> any other questions or thoughts about the midcycle?
16:08:01 <gagehugo> not atm
16:08:44 <lbragstad> ok - sounds like we can move on then
16:08:53 <lbragstad> #topic including oslo.limit in train
16:08:57 <lbragstad> bnemec o/
16:09:08 <bnemec> Hey
16:09:22 <bnemec> I saw in the last release update email that the deadline for inclusion into Train is coming up.
16:09:40 <bnemec> Which I _think_ means if we want to do a release of oslo.limit this cycle we need to do it soon.
16:09:42 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007552.html
16:10:03 <bnemec> Thanks
16:10:26 <bnemec> I realize no one's going to have switched to it yet this cycle, but without a release it will be tougher to test in other projects.
16:10:34 <lbragstad> i know we talked about oslo.limit stuff a couple of weeks ago during this meeting
16:10:55 <lbragstad> i need to get started on those action items
16:11:09 <lbragstad> but it sounds like we just need *a* release, right?
16:11:39 <bnemec> Yeah, that's what I'm thinking. Just release it as-is so we have a placeholder and can do further releases later in the cycle.
16:12:18 <lbragstad> ++
16:12:28 <cmurphy> that sounds fine to me
16:12:41 <lbragstad> just a v 0.1.0
16:12:42 <lbragstad> ?
16:13:29 <bnemec> Yeah, whatever our minimum version is.
16:13:35 <lbragstad> ok
16:13:40 <lbragstad> i can take an action to do that today
16:14:05 <lbragstad> #action lbragstad to propose an oslo.limit release and follow up with tonyb to make sure it is included in Train
16:14:15 <bnemec> Cool, thanks.
16:14:23 <lbragstad> np - thanks for raising that
16:14:57 <lbragstad> #topic spec reviews
16:15:04 <lbragstad> #link https://review.opendev.org/624692 (immutable resources)
16:15:30 <lbragstad> https://review.opendev.org/604201 (expiring group membership)
16:15:33 <lbragstad> #link https://review.opendev.org/604201 (expiring group membership)
16:15:43 <lbragstad> #link https://review.opendev.org/661837 (expose root domain)
16:15:58 <lbragstad> looks like all of those need some eyes - i have some comments to address on the last one
16:15:58 <cmurphy> so we're a couple weeks out from spec freeze so i thought it would be good to get some updates on the remaining open specs
16:16:35 <cmurphy> immutable resources has 2 +2s but it would be nice to have someone else give it a last look and push the button
16:16:51 <lbragstad> i guess i co-authored that one
16:17:18 <gagehugo> I'll take a look
16:17:27 <cmurphy> ty
16:18:00 <cmurphy> knikolla: any update on the expiring group membership spec?
16:18:24 <knikolla> cmurphy: no updates as of now, the past few weeks i haven't had the change to touch anything keystone
16:18:45 <knikolla> i have set time aside this week to catch up on work
16:18:57 <knikolla> rest of today i will update the spec and respond to comments
16:19:10 <cmurphy> okay
16:19:32 <cmurphy> lbragstad: any concerns about the expose root domain spec?
16:19:49 <lbragstad> i'll be responding to your comments today, too
16:19:56 <lbragstad> i won't be able to work on it though
16:20:43 <cmurphy> hmm okay
16:20:56 <cmurphy> can anyone else volunteer to pick up that work for this cycle?
16:21:36 <cmurphy> if not maybe we should change it from the train/ directory to backlog/
16:21:52 <lbragstad> that makes sense
16:23:11 <gagehugo> ++
16:24:07 <cmurphy> okay sounds like we may have to do that
16:24:48 <cmurphy> #agreed move https://review.opendev.org/661837 to Backlog instead of Train
16:25:09 * lbragstad left a comment on the review
16:25:14 <lbragstad> i'll address those today
16:25:31 <cmurphy> thanks lbragstad
16:25:35 <lbragstad> mhmmm
16:25:41 <lbragstad> anything else on spec discussion?
16:25:44 <cmurphy> that's all i had on those topics
16:25:54 <lbragstad> cool
16:26:00 <lbragstad> moving on
16:26:06 <lbragstad> #topic open reviews
16:26:49 <lbragstad> i wouldn't mind another set of eyes on the unified limits doc
16:26:51 <lbragstad> #link https://review.opendev.org/#/c/664933/
16:27:14 <cmurphy> i wanted to bring attention to https://review.opendev.org/637305 though i just realized it's in merge conflict, will fix but otherwise it's ready to go
16:27:42 <lbragstad> cool
16:27:48 <cmurphy> also this was one outcome from the ptg that i'd like feedback on https://review.opendev.org/669004
16:28:18 <lbragstad> i remember that conversation - i'll take a look
16:28:24 <cmurphy> ty
16:28:50 <vishakha> I added support for app creds in sdk https://review.opendev.org/#/c/669331/. Open for review
16:28:58 <cmurphy> nice vishakha
16:30:03 <vishakha> Also https://review.opendev.org/#/c/660609/  needs one more +2
16:30:56 <gagehugo> vishakha: done
16:30:58 <lbragstad> nice
16:31:36 <vishakha> cmurphy lbragstad gagehugo thanks
16:32:10 <lbragstad> any other reviews that need attention?
16:32:40 <vishakha> One last https://review.opendev.org/#/c/659434/
16:33:03 <cmurphy> oh that one i wanted to talk about here
16:33:11 <cmurphy> i'm not sure i agree with changing the error message
16:33:22 <cmurphy> anyone else have thoughts on it? https://review.opendev.org/#/c/659434/21/keystone/exception.py
16:34:12 <gagehugo> hmm
16:34:16 <lbragstad> the status code remains the same
16:34:21 <cmurphy> right
16:34:26 <vishakha> sure. we can have more thoughts over it
16:34:56 <lbragstad> cmurphy you want to keep it the same?
16:35:30 <gagehugo> I would assume it should say that the API is no longer supported or available
16:35:41 <cmurphy> i'm on the fence, i guess the new error message is much more honest but the old one was kind of technically correct
16:36:27 <lbragstad> after reading the old one, i wouldn't want operators to go digging in configuration files to fix a 500 when they can't really do anything about it anyway
16:36:30 <gagehugo> maybe mix them together, keep the first sentence of the old one but change the second half to say it's no longer supported?
16:36:41 <cmurphy> lbragstad: that's fair
16:37:28 <lbragstad> i think technicall we should be using a 410 for this?
16:37:37 <lbragstad> technically*
16:37:54 <cmurphy> gagehugo: that makes sense, maybe "Expected signing certificates are not available on the server because the OS-SIMPLE-CERT API is no longer supported"
16:38:04 <lbragstad> +1
16:38:05 <cmurphy> lbragstad: i wouldn't want to change the code for this
16:38:17 <gagehugo> cmurphy: yeah
16:38:24 <lbragstad> because we technically can't, right
16:38:26 <lbragstad> ?
16:38:28 <cmurphy> right
16:38:45 <cmurphy> well maybe we technically can change a 5XX->4XX but i don't think it's appropriate
16:39:10 <lbragstad> how so?
16:39:44 <cmurphy> we deliberately raised a 500 before and i think it makes sense to keep it because the reason for raising it isn't different (the server isn't set up to handle it)
16:41:08 <lbragstad> yeah
16:42:02 <lbragstad> i guess with 500s a client might retry intermittently hoping the server issue has been resolved
16:42:37 <lbragstad> with a 410 the server is explicitly saying "no matter how many times you ask for this resource, it no longer exists"
16:43:40 <cmurphy> that's valid
16:43:53 <lbragstad> i can see both sides
16:44:30 * lbragstad stops playing devil's advocate
16:45:30 <cmurphy> i feel like we're crossing the line of changing this API if we fully admit that it's Gone, where everything else in that patch tries to keep things mostly the same except for the removed config options
16:45:58 <lbragstad> yeah - i can see that
16:46:03 <cmurphy> it's like if we changed the revocation API to return a 410 instead of []
16:46:22 <cmurphy> that wouldn't have been right
16:46:39 <lbragstad> yeah - that would have been going from 200 to 410
16:48:46 <lbragstad> so we have the following options
16:49:08 <lbragstad> 1.) keep the API the same and return a 500
16:49:29 <lbragstad> optionally improve the error message to be more informative that the API is actually gone
16:50:04 <lbragstad> 2.) make the http status code reflect the error message and advertise a 410 Gone
16:51:09 <cmurphy> i'm in favor of 1, but i imagine kmalloc might have an opinion on it and/or we can ask the api-sig for advice
16:51:29 <lbragstad> #1 doesn't change the API but might be misleading to clients (especially non-human clients)
16:51:47 <lbragstad> #2 is a higher bar
16:52:04 <lbragstad> +1 to asking the api sig
16:53:24 <vishakha> Should I ask api-sig team for this then?
16:53:54 <cmurphy> we could bring it up at their next office hour session
16:54:12 <vishakha> That seems a good option
16:54:40 <lbragstad> #link http://eavesdrop.openstack.org/#API_Special_Interest_Group_office_hours
16:56:31 <lbragstad> 4 minutes left
16:56:37 <lbragstad> anything else for reviews?
16:57:56 <lbragstad> #topic open discussion
16:58:09 <cmurphy> i don't have anything for office hours today
16:58:15 <cmurphy> but i think we should do a bug triage next week
16:58:21 <lbragstad> ++
16:59:40 <lbragstad> anything else?
16:59:53 <cmurphy> thanks for chairing lbragstad
16:59:59 <lbragstad> anytime cmurphy
17:00:02 <vishakha> thanks all
17:00:07 <lbragstad> thanks everyone!
17:00:10 <lbragstad> #endmeeting