17:01:16 #startmeeting keystone 17:01:16 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:19 The meeting name has been set to 'keystone' 17:01:32 #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda 17:01:37 o/ 17:01:37 o/ 17:01:39 good morning/evening 17:02:27 o/ 17:04:56 #topic announcements 17:05:30 as an fyi i'll be on vacation next week, knikolla has agreed to take over ptling while i'm gone 17:05:37 o/ 17:05:39 thanks knikolla :D 17:06:05 cmurphy: np :) 17:07:05 #topic Avoid project creation on default domain (raildo) 17:07:08 raildo: you're up 17:07:25 hey all :) so I'll try to be quick on this one 17:08:12 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 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 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 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 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 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 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 o/ 17:12:00 cmurphy, openstack cli 17:12:09 hmm 17:12:52 this reminds me of https://bugs.launchpad.net/keystone/+bug/1498556 17:12:54 Launchpad bug 1498556 in python-openstackclient "Reasonable assumptions concerning domain references" [Undecided,Triaged] 17:13:39 yeah, it might be the same scenario 17:15:22 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 ah, good ol henry 17:16:01 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 oh huh i thought it was the cli doing that 17:16:22 that conflicts with what the api-ref says about it 17:16:47 cmurphy, right, so I can create a bug for it and send a patch if you want 17:17:10 #link https://bugs.launchpad.net/tempest/+bug/1283539 17:17:15 Launchpad bug 1283539 in tempest "Tempest heat test calls keystone v3 user api with domain_id" [Undecided,Expired] 17:17:19 lbragstad, thanks for the link! :D 17:17:23 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 raildo no problem 17:17:46 this seems like it might be api-breaking :/ 17:19:44 "There is no plan to remove this compatibility, however, future API versions may remove this" 17:19:50 henry thought of this 17:19:59 this would have to wait until v4 :( 17:20:29 damn =/ 17:20:29 yeah, this is definitely API breaking and will break a lot of people. 17:21:09 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 that seems like the best way to go 17:21:28 i think that's fair 17:21:53 +1 17:22:04 great, so we have a plan :) 17:22:32 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 that way we don't lose track of it 17:22:57 cmurphy, cool, I'll do that! 17:23:03 great 17:23:08 thanks everyone! 17:23:16 thanks raildo 17:23:39 #topic YVR event attendance poll 17:24:30 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 o/ 17:25:04 i know nobody knows until like the very last minute but your best hunch is fine 17:25:35 i'm tentatively attending o/ 17:25:53 * lbragstad has absolutely no idea what our team plans are for YVR 17:26:03 but i will make a point to ask this week 17:26:09 er - next week 17:26:19 cool 17:26:34 I have no idea, I'll ask next week too 17:27:02 i will bw attending too 17:27:22 cool 17:27:27 raildo: what about you? 17:28:03 cmurphy, good question, probably not =/ 17:28:35 :'( 17:29:04 i'll wait to respond till i'm back from vacation but tentatively thinking i'll ask for a room 17:29:55 cmurphy i know it's early 17:30:08 but do you have anything you're looking to tackle during the PTG? 17:32:43 good question 17:33:07 my main concern is still the cross-project policy work 17:33:45 and possibly making more progress with unified limits 17:34:34 * lbragstad needs to look at nova's policy patches 17:36:47 would also be good to tackle some housekeeping things - prioritize some technical debt, bugs, old specs, update our liaison list 17:37:03 ++ 17:37:26 and generally just get the next ptl started on the right foot :) 17:37:42 i'll get a brainstorming etherpad out 17:37:50 thanks cmurphy 17:38:11 thanks lbragstad 17:38:15 mhm 17:38:25 #topic Contributing guide goal 17:38:44 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012364.html community goal 17:38:56 there was a new community goal added recently 17:39:09 it should be pretty easy, i was wondering if anyone was interested in tackling it? 17:40:16 I can take a look as soon as I will complete my openstack_groups task 17:40:35 thanks vishakha :) 17:40:36 awesome, thanks vishakha 17:40:47 i'm going to add it to the taiga roadmap board 17:40:57 sure Thanks 17:41:40 #topic L1 duty rotation 17:41:51 I was on duty last week 17:43:02 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 Launchpad bug 1808305 in python-keystoneclient "discrepancy in response of "check_*" methods" [Undecided,New] 17:43:56 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 that's fair 17:44:43 ++ 17:45:43 cool, will do that 17:46:11 fyi there are 91 keystone bugs that are "Triaged" or "Confirmed" if anyone is looking to dive into some code :) 17:46:32 knikolla is on next week, vishakha can you take the week after? 17:46:49 yes I will take after next week 17:47:14 thanks :) 17:47:44 #topic Review requests 17:48:42 #link https://review.opendev.org/705859 immutable roles default 17:49:01 ^ that's a followup from the immutable roles spec from last cycle, needs to be merged before feature freeze this cycle 17:51:11 #link https://review.opendev.org/#/c/705887/ 17:51:13 easy one ^ 17:51:31 #link https://review.opendev.org/#/c/697444/ osc resource options 17:51:56 thanks vishakha for those 17:51:58 any others? 17:52:09 yup, thanks. will review this afternoon :) 17:52:22 thanks knikolla 17:53:41 #topic open floor 17:53:47 any other business? 17:55:27 okay thanks y'all 17:55:30 #endmeeting