17:01:16 <cmurphy> #startmeeting keystone
17:01:16 <openstack> Meeting started Tue Feb 11 17:01:16 2020 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:19 <openstack> The meeting name has been set to 'keystone'
17:01:32 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
17:01:37 <vishakha> o/
17:01:37 <knikolla> o/
17:01:39 <cmurphy> good morning/evening
17:02:27 <gagehugo> o/
17:04:56 <cmurphy> #topic announcements
17:05:30 <cmurphy> as an fyi i'll be on vacation next week, knikolla has agreed to take over ptling while i'm gone
17:05:37 <raildo> o/
17:05:39 <cmurphy> thanks knikolla :D
17:06:05 <knikolla> cmurphy: np :)
17:07:05 <cmurphy> #topic Avoid project creation on default domain (raildo)
17:07:08 <cmurphy> raildo: you're up
17:07:25 <raildo> hey all :) so I'll try to be quick on this one
17:08:12 <raildo> basically, nowadays, during a project creation we have 3 option regarding setting up the domain_id, first of all, the user can pass it as a project parameter
17:08:42 <raildo> 2 option, if the user didn't pass it, and it's using a domain scoped token, we extract the domain_id from the token context
17:09:19 <raildo> and the 3 option, if a user didn't passed the domain_id, it's using just a project scoped token, we set that project to the default domain
17:09:59 <raildo> well, this 3rd option was created to keep backward compatibility with keystone v2.0 which I think it's not the case anymore
17:10:23 <raildo> so I would like to avoid this "domain default" situation, since can cause a lot of trouble in production, what you think?
17:11:14 <raildo> my suggestion would be changing this third option to raise an exception and just accept the first two option that Keystone already accept
17:11:45 <cmurphy> raildo: what cli/library/tool are you using to create projects? the v3 api doesn't make any assumption about the default domain
17:11:59 <lbragstad> o/
17:12:00 <raildo> cmurphy, openstack cli
17:12:09 <gagehugo> hmm
17:12:52 <cmurphy> this reminds me of https://bugs.launchpad.net/keystone/+bug/1498556
17:12:54 <openstack> Launchpad bug 1498556 in python-openstackclient "Reasonable assumptions concerning domain references" [Undecided,Triaged]
17:13:39 <raildo> yeah, it might be the same scenario
17:15:22 <lbragstad> we'd need to raise the exception here? https://opendev.org/openstack/keystone/src/branch/master/keystone/server/flask/common.py#L980-L998
17:15:55 <gagehugo> ah, good ol henry
17:16:01 <lbragstad> afaict - ^ that's what populating the default domain id when it isn't set, or the user isn't using a domain-scoped tokne
17:16:15 <cmurphy> oh huh i thought it was the cli doing that
17:16:22 <cmurphy> that conflicts with what the api-ref says about it
17:16:47 <raildo> cmurphy, right, so I can create a bug for it and send a patch if you want
17:17:10 <gagehugo> #link https://bugs.launchpad.net/tempest/+bug/1283539
17:17:15 <openstack> Launchpad bug 1283539 in tempest "Tempest heat test calls keystone v3 user api with domain_id" [Undecided,Expired]
17:17:19 <raildo> lbragstad, thanks for the link! :D
17:17:23 <lbragstad> note - this is going to break clients who don't use domain-scoped tokens to create projects and don't specify domains in project references
17:17:39 <lbragstad> raildo no problem
17:17:46 <cmurphy> this seems like it might be api-breaking :/
17:19:44 <cmurphy> "There is no plan to remove this compatibility, however, future API versions may remove this"
17:19:50 <cmurphy> henry thought of this
17:19:59 <cmurphy> this would have to wait until v4 :(
17:20:29 <raildo> damn =/
17:20:29 <knikolla> yeah, this is definitely API breaking and will break a lot of people.
17:21:09 <raildo> so should we at least improve our docs and say that it'll point for the default domain, and suggest ppl to not use on this way?
17:21:26 <knikolla> that seems like the best way to go
17:21:28 <lbragstad> i think that's fair
17:21:53 <cmurphy> +1
17:22:04 <raildo> great, so we have a plan :)
17:22:32 <cmurphy> raildo: you could also open a bug and add the tag fix-requires-microversion https://bugs.launchpad.net/keystone/+bugs?field.tag=fix-requires-microversion those are basically all of our "when we're ready for v4" plans
17:22:40 <cmurphy> that way we don't lose track of it
17:22:57 <raildo> cmurphy, cool, I'll do that!
17:23:03 <cmurphy> great
17:23:08 <raildo> thanks everyone!
17:23:16 <cmurphy> thanks raildo
17:23:39 <cmurphy> #topic YVR event attendance poll
17:24:30 <cmurphy> it's that time of year when the foundation people ask me if we need space at the next ptg so i wanted to get a show of hands of people who think they might be there
17:24:45 <knikolla> o/
17:25:04 <cmurphy> i know nobody knows until like the very last minute but your best hunch is fine
17:25:35 <cmurphy> i'm tentatively attending o/
17:25:53 * lbragstad has absolutely no idea what our team plans are for YVR
17:26:03 <lbragstad> but i will make a point to ask this week
17:26:09 <lbragstad> er - next week
17:26:19 <cmurphy> cool
17:26:34 <gagehugo> I have no idea, I'll ask next week too
17:27:02 <vishakha> i will bw attending too
17:27:22 <cmurphy> cool
17:27:27 <cmurphy> raildo: what about you?
17:28:03 <raildo> cmurphy, good question, probably not =/
17:28:35 <cmurphy> :'(
17:29:04 <cmurphy> i'll wait to respond till i'm back from vacation but tentatively thinking i'll ask for a room
17:29:55 <lbragstad> cmurphy i know it's early
17:30:08 <lbragstad> but do you have anything you're looking to tackle during the PTG?
17:32:43 <cmurphy> good question
17:33:07 <cmurphy> my main concern is still the cross-project policy work
17:33:45 <cmurphy> and possibly making more progress with unified limits
17:34:34 * lbragstad needs to look at nova's policy patches
17:36:47 <cmurphy> would also be good to tackle some housekeeping things - prioritize some technical debt, bugs, old specs, update our liaison list
17:37:03 <lbragstad> ++
17:37:26 <cmurphy> and generally just get the next ptl started on the right foot :)
17:37:42 <cmurphy> i'll get a brainstorming etherpad out
17:37:50 <lbragstad> thanks cmurphy
17:38:11 <cmurphy> thanks lbragstad
17:38:15 <lbragstad> mhm
17:38:25 <cmurphy> #topic Contributing guide goal
17:38:44 <cmurphy> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012364.html community goal
17:38:56 <cmurphy> there was a new community goal added recently
17:39:09 <cmurphy> it should be pretty easy, i was wondering if anyone was interested in tackling it?
17:40:16 <vishakha> I can take a look as soon as I will complete my openstack_groups task
17:40:35 <cmurphy> thanks vishakha :)
17:40:36 <knikolla> awesome, thanks vishakha
17:40:47 <cmurphy> i'm going to add it to the taiga roadmap board
17:40:57 <vishakha> sure Thanks
17:41:40 <cmurphy> #topic L1 duty rotation
17:41:51 <cmurphy> I was on duty last week
17:43:02 <cmurphy> there should be no more bugs for ksm or ksa in state "New", only three still in "New" for keystone, one for ksc that I'd like to discuss https://bugs.launchpad.net/python-keystoneclient/+bug/1808305
17:43:03 <openstack> Launchpad bug 1808305 in python-keystoneclient "discrepancy in response of "check_*" methods" [Undecided,New]
17:43:56 <cmurphy> it's "New" but actually over a year old, I'm leaning toward closing it as wontfix - I don't think getting consistency is worth the deprecation hassle, especially not for ksc
17:44:33 <lbragstad> that's fair
17:44:43 <knikolla> ++
17:45:43 <cmurphy> cool, will do that
17:46:11 <cmurphy> fyi there are 91 keystone bugs that are "Triaged" or "Confirmed" if anyone is looking to dive into some code :)
17:46:32 <cmurphy> knikolla is on next week, vishakha can you take the week after?
17:46:49 <vishakha> yes I will take after next week
17:47:14 <cmurphy> thanks :)
17:47:44 <cmurphy> #topic Review requests
17:48:42 <cmurphy> #link https://review.opendev.org/705859 immutable roles default
17:49:01 <cmurphy> ^ that's a followup from the immutable roles spec from last cycle, needs to be merged before feature freeze this cycle
17:51:11 <cmurphy> #link https://review.opendev.org/#/c/705887/
17:51:13 <cmurphy> easy one ^
17:51:31 <cmurphy> #link https://review.opendev.org/#/c/697444/ osc resource options
17:51:56 <cmurphy> thanks vishakha for those
17:51:58 <cmurphy> any others?
17:52:09 <knikolla> yup, thanks. will review this afternoon :)
17:52:22 <cmurphy> thanks knikolla
17:53:41 <cmurphy> #topic open floor
17:53:47 <cmurphy> any other business?
17:55:27 <cmurphy> okay thanks y'all
17:55:30 <cmurphy> #endmeeting