Wednesday, 2022-09-28

gansovishalmanchanda: hi! have you had any chance to give another try at https://review.opendev.org/c/openstack/horizon/+/856308 ?13:16
vishalmanchandaganso: sorry I forgot:(.13:59
gansovishalmanchanda: I posted new findings in the LP14:00
gansovishalmanchanda: I may have found why you were unable to reproduce, there are specific combinations where the problem does not happen14:00
gansovishalmanchanda: unfortunately those combinations are not useful for my customer, they are still stuck14:01
vishalmanchandaganso: looking at your findings in the LP.14:01
vishalmanchanda#startmeeting horizon15:00
opendevmeetMeeting started Wed Sep 28 15:00:15 2022 UTC and is due to finish in 60 minutes.  The chair is vishalmanchanda. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'horizon'15:00
gansoo/15:00
tmazuro/15:00
rdopierao/15:00
vishalmanchandaHello everyone15:01
vishalmanchandaThere is no update from my side for this week.15:01
vishalmanchandaso moving to open-discussion15:02
vishalmanchanda#topic open-discussion15:02
gansohas anyone been able to take a look at https://review.opendev.org/c/openstack/horizon/+/856308 ?15:02
vishalmanchandaI was busy in some interanl work so didn't get a chance to review it.15:04
vishalmanchandaganso: will review it soon.15:04
gansovishalmanchanda: thanks15:04
rdopieraganso: that really looks to me like the problem is in a different place -- namely with the check where it fails when the domain token exists15:06
rdopieraganso: do you think it would be possible to fix it there, instead of adding such workaround to horizon?15:07
gansordopiera: hmmm what other possible place are you suggesting? I checked keystone and it doesn't seem to be there15:07
rdopieraganso: well, you get an error somewhere form that api call, no?15:08
gansordopiera: given the CLI always works also hints that the fix has to be in horizon15:08
gansordopiera: there is no error per se, it is not just a different behavior15:08
gansordopiera: the API doesn't error out, and the API call and parameters are exactly the same as the CLI, except for the token15:09
gansordopiera: keystone receives the API call and derives the context from the token suplied15:09
gansordopiera: so the API is also not the issue, it is the token being sent15:09
gansordopiera: if the CLI is sending a token and getting the correct result, and Horizon is sending another token and getting a different result, seems like the problem is around selecting which token to send, which Horizon's code does15:10
rdopieraganso: then maybe there should be an option added to force sending a specific kind of token?15:10
gansordopiera: that's exactly what the proposed fix is doing15:11
gansordopiera: but not as an option, but trying to match the behavior to the CLI, deemed as the "expected" behavior15:11
rdopierano, the proposed fix is monkey-patching the request object to get around a check that is later in the code15:11
gansordopiera: yea, but achieving the intended result15:12
rdopieraand making everything harder to understand and maintain15:12
gansordopiera: but when you say "an option" it sounds user-facing or controlled15:13
gansordopiera: indeed, I don't like the approach much, but a config option or a button in the UI will be a more dramatic change, which is worth discussing here15:14
gansothat's part of the point of bringing it to discussion15:14
rdopieraI don't mean a config option, I mean an option you can pass when calling the keystone functions15:14
gansordopiera: a config option would need to be well thought out as to which workflows it would affect. It seems this is the only workflow that is being affected by this token issue15:15
rdopierathis way 1. it's fixed where it's actually handled, 2. other api calls can use it too15:15
gansordopiera: oh so you mean, do the same thing but in a less ugly way ?15:15
rdopieranot a config option15:15
rdopieraa parameter15:15
rdopieraperhaps when creating keystoneclient15:15
gansordopiera: I see, I have looked at the code, I don't have the exact line codes and filename handy right now but I know the code that performs the decision on whether to use the domain_token or the user_token (in keystoneclient), what you suggesting is a parameter when creating the keystoneclient like "force_user_token=True" which would make the solution clean, and the app cred call would just pass that to the keystoneclient15:18
gansordopiera: instead of doing that request token reshuffling15:18
gansordopiera: correct?15:18
rdopieralook at line 155 of that file15:19
rdopieracorrect 15:19
gansordopiera: oh yes, exactly, that's the one, I forgot the "keystoneclient()" was in the same file15:20
gansoln 15515:20
gansordopiera: it is just basically avoid line 157 with a new flag passed as parameter15:21
rdopieraI don't know this code too well myself, but I would think the fix should be around there somewhere15:21
gansordopiera: sounds good, I agree, looks cleaner, produces the same result15:22
gansordopiera: I will make the changes15:22
vishalmanchandardopiera: ganso :thanks for discussion.15:23
gansordopiera: BUT, the original concern I raised last week still stands whether we bug is actually intended behavior or not, but based on all the evidence I see barely any argument in favor to say that it is, mainly due to the fact that the beahvior is different than the CLI15:23
gansos/we bug/the bug15:24
rdopieraas long as it doesn't break things for other users...15:24
gansordopiera: given the new parameter will be only used in create app cred, it won't. However, I hope it doesn't break users that are intending to create app cred WITHOUT project_id, which I don't see why anyone would be needing that15:25
amotokiperhaps it happens due to the fact that horizon assume the scope based on which panel is used but we may need more explicit scope.15:25
rdopieraadding a parameter would be a step in the right direction15:27
ganso+115:27
gansogreat, thanks for the discussion =)15:27
rdopieratmazur: you wanted to talk about tests?15:30
tmazurvishalmanchanda: could you please take a look at https://review.opendev.org/c/openstack/horizon/+/819725/ ?15:30
vishalmanchandatmazur: sure, will test it after the meeting or tommorow morning.15:31
tmazurIt seems changes in webdriver.py make the integration tests more stable15:31
tmazurSo probably if we have it merged it will improve integration tests stability in general15:32
tmazurvishalmanchanda: thanks!15:32
vishalmanchandagreat.15:33
vishalmanchandaDoes anyone have any other topic to discuss?15:34
vishalmanchandaif nothing more to discuss, let end this meeting15:38
vishalmanchandaA reminder about adding topics for antelope PTG15:38
vishalmanchandahttps://etherpad.opendev.org/p/horizon-antelope-ptg15:38
vishalmanchandaThanks everyone for your contributions!15:38
vishalmanchanda#endmeeting15:39
opendevmeetMeeting ended Wed Sep 28 15:39:07 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:39
opendevmeetMinutes:        https://meetings.opendev.org/meetings/horizon/2022/horizon.2022-09-28-15.00.html15:39
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/horizon/2022/horizon.2022-09-28-15.00.txt15:39
opendevmeetLog:            https://meetings.opendev.org/meetings/horizon/2022/horizon.2022-09-28-15.00.log.html15:39
tobias-urdinvishalmanchanda: any chance i could get some reviews and input on https://review.opendev.org/c/openstack/horizon/+/844574 ?17:20
opendevreviewMerged openstack/horizon master: Integration test navigation machinery for Angular pages  https://review.opendev.org/c/openstack/horizon/+/81972519:12
opendevreviewRodrigo Barbieri proposed openstack/horizon master: Fix app cred create without project_id for domain admins  https://review.opendev.org/c/openstack/horizon/+/85630821:18

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!