| opendevreview | Takashi Kajinami proposed openstack/horizon master: DNM: testing https://review.opendev.org/c/openstack/horizon/+/998286 | 09:45 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/horizon master: DNM: testing https://review.opendev.org/c/openstack/horizon/+/998286 | 10:37 |
| opendevreview | Takashi Kajinami proposed openstack/horizon master: Regenerate keystone default policy rules https://review.opendev.org/c/openstack/horizon/+/998291 | 10:37 |
| opendevreview | Takashi Kajinami proposed openstack/horizon master: Regenerate default policy rules https://review.opendev.org/c/openstack/horizon/+/998291 | 10:37 |
| opendevreview | Takashi Kajinami proposed openstack/horizon master: DNM: testing https://review.opendev.org/c/openstack/horizon/+/998286 | 10:37 |
| tkajinam | rdopiera, I sill have to check integration tests but so far https://review.opendev.org/c/openstack/horizon/+/998291 is enough to fix scope error | 10:43 |
| tkajinam | the default policy files are quite outdated. The critical problem was that it does not include the required changes in keystone policies to allow domain scoped access | 10:44 |
| tkajinam | which should be fixed during regenerating the policy rules | 10:44 |
| rdopiera | tkajinam: thanks for looking into it, but I think it still doesn't make sense to have all this brittle code to satisfy an artificial check in oslo.policy that serves no purpose otherwise | 10:46 |
| tkajinam | it's not an artifical check in oslo.policy really | 10:46 |
| rdopiera | what do we gain in horizon from it? | 10:46 |
| tkajinam | horizon uses domain scope token to access keystone so any policy rule for keystone should be evaluated with domain scope credential | 10:47 |
| rdopiera | that's fine, but what advantage does the check give us? | 10:47 |
| tkajinam | (more precisely speaking, only when domain scoped credential is present) | 10:47 |
| tkajinam | for example if different scope allows different roles then the visibility control doesn't work a expected. | 10:48 |
| rdopiera | thew way I see it, we have a piece of code on one side that checks a certain condition, and we have to write a piece of code on the other side that satisfies the condition, and there is absolutely nothing that relates to otherwise | 10:48 |
| tkajinam | I understand horizon does not expose scope but as long as it uses scope in that way, in its intentional way, it should be able to evaluate policy rules according to the way it internally uses scopes | 10:49 |
| rdopiera | but there is no connection between how we call oslo.policy and how we call api endpoints | 10:49 |
| rdopiera | it's completely separate code | 10:49 |
| tkajinam | these are completely separate in code layer but these are currently consistently implemented | 10:50 |
| tkajinam | it uses domain scope for keystone, project scope for the others | 10:50 |
| tkajinam | then it should use domain scope when evaluating policy for keystone, project scope for the others | 10:50 |
| rdopiera | as far as oslo.policy is concerned, we have always used domain scope for everything, because we always pass domain_id in the credentials | 10:51 |
| tkajinam | the policy evaluation and credential selection are implemented in different layers, which is confusing, but that's how I understand the current implementation | 10:51 |
| rdopiera | it has been that for as long as we use oslo.policy | 10:51 |
| tkajinam | I mean | 10:51 |
| tkajinam | it doens't use "domain credential" for all. credentail here is too much confusing terminology | 10:52 |
| tkajinam | it uses project-scoped "token" for non-keystone and domain-scoped "token" for keystone | 10:52 |
| tkajinam | credential in that layer is more like a metadata, associated with that token | 10:52 |
| rdopiera | there are no tokens involved | 10:52 |
| tkajinam | involved with what ? policy rules evaluation ? then it's correct | 10:54 |
| tkajinam | I mean token itself is not involved in policy rules | 10:54 |
| rdopiera | we are calling apis, not validating them, so the answer to the question "what is the scope of that token" is "which want to do you want" | 10:54 |
| tkajinam | but policy rules should be evaluated with the metadata which actually represents scope of that token | 10:54 |
| rdopiera | which one do you want | 10:54 |
| rdopiera | sorry, typos | 10:54 |
| tkajinam | np | 10:54 |
| rdopiera | by the way, I was wondering, is the a way to call something in oslo.policy with a rule, and have it tell us what scope it needs? | 10:55 |
| tkajinam | https://github.com/openstack/horizon/blob/9ca3e129ea64be0b00c81fad986a7f5ae1d2583c/openstack_dashboard/api/keystone.py#L153-L165 | 10:55 |
| tkajinam | let me check but I guess no | 10:56 |
| tkajinam | but technically we can expose such api, I think | 10:56 |
| rdopiera | it would feel a bit like "tell me what the password is, so I can tell you the password", but it would make it easier | 10:57 |
| rdopiera | generally speaking, when we are calling oslo.policy checks in horizon, we are asking "is this user allowed to do this, with any scope?" | 10:59 |
| rdopiera | and then later the code that actually calls the api takes care of picking the aright cope for the particular api endpoints | 11:00 |
| tkajinam | that works of cause but just exposes more non-functional buttons. horiozn knows which token would be used it could make earlier decision about the scope. | 11:04 |
| tkajinam | a problem you would see is when you configure horizon to prefer domain scoped credential for keystone, then you find a few buttons available but is not functioning due to keystone not allowing domain scope credential for api | 11:04 |
| rdopiera | it uses whatever token works for the given call | 11:05 |
| rdopiera | it doesn't know up front | 11:05 |
| tkajinam | is there any token fallback mechanism ? | 11:05 |
| rdopiera | afaik we just hardcode which one to use for which call, at the moment | 11:05 |
| rdopiera | but oslo.policy is not invovled in that | 11:06 |
| tkajinam | so if the hard-coded scope doesn't work then it never works | 11:07 |
| rdopiera | I suppose we could make each call to oslo.policy three times, with different scopes, and return true if any of them returns true | 11:07 |
| tkajinam | if horizon implements scope fallback really | 11:08 |
| rdopiera | I have no idea if it does or how it's supposed to work | 11:08 |
| tkajinam | just to make my stance clear, I won't block that change really but find it wired because if is not fully aligned with policy rule mechanism from oslo.policy | 11:08 |
| rdopiera | yeah, I thin oslo.policy is not really designed with UI in mind | 11:08 |
| tkajinam | I hope gmaan would provide better guidance about it. | 11:09 |
| tkajinam | the whole concept was messed up when we decided to "isolate" scopes for number of reasons | 11:09 |
| rdopiera | I would have to have a cross-project session on the PTG about how we could make oslo.policy easier to use in horizon | 11:09 |
| tkajinam | (I mean, when we decided that domain scope can't handle project-scoped things. and etc. | 11:09 |
| rdopiera | I still don't understand what we are supposed to do with system scope exactly | 11:09 |
| rdopiera | from the user interface point of view, I mean | 11:10 |
| tkajinam | with current design anything other than project scope doesn't work | 11:10 |
| tkajinam | so ignore it now. that's my suggestion. | 11:11 |
| rdopiera | thanks, that's what I've been doing, pretty much, but it's still a thorn in my side | 11:11 |
| tkajinam | The initial aim was that system scope can access anything in any projects. | 11:11 |
| tkajinam | but it no longer works like that | 11:11 |
| tkajinam | after isolation | 11:12 |
| rdopiera | we are in no hurry with this patch, since the gate is unblocked, so let's wait for gmaan to comment | 11:13 |
| rdopiera | thank you again for looking into this, I really appreciate help from someone who is more familiar with the entire policy thing | 11:14 |
| tkajinam | :-) | 11:19 |
| tmazur | #startmeeting horizon | 15:00 |
| opendevmeet | Meeting started Wed Jul 22 15:00:17 2026 UTC and is due to finish in 60 minutes. The chair is tmazur. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'horizon' | 15:00 |
| tmazur | Hello everyone and welcome to the weekly meeting! | 15:00 |
| blasseye- | Hi everyone ! | 15:00 |
| omcgonag | o/ | 15:01 |
| jjasek | Hello | 15:01 |
| rdopiera | aloha | 15:01 |
| tmazur | Let's begin | 15:02 |
| tmazur | Agenda for today is here: https://etherpad.opendev.org/p/horizon-release-priorities#L39 | 15:03 |
| tmazur | #topic Notices | 15:04 |
| tmazur | This week is R-10 | 15:04 |
| tmazur | Hibiscus Release Schedule: https://releases.openstack.org/hibiscus/schedule.html | 15:04 |
| tmazur | 2027.1 "Indri" release schedule is proposed: | 15:05 |
| tmazur | 996808: Proposed 2027.1 Indri release schedule | https://review.opendev.org/c/openstack/releases/+/996808 | 15:05 |
| tmazur | That's all for the announcements for today | 15:07 |
| tmazur | #topic Release priorities | 15:07 |
| tmazur | 977939: Add Horizon panel to enable TOTP MFA enrollment | https://review.opendev.org/c/openstack/horizon/+/977939 | 15:08 |
| tmazur | blasseye- Would you like to share your status on this one? | 15:08 |
| blasseye- | Let's put this review on hold for now, and I'll take care of the keystone correction so we don't get stuckif we delete credential. Once it's approved, we can discuss it further. i think it's a good way | 15:08 |
| tmazur | Could you share the keystone patch link please? | 15:09 |
| tmazur | 985969: Fix: TOTP authentication lockout risk in Keystone | https://review.opendev.org/c/openstack/keystone/+/985969 | 15:09 |
| tmazur | This one ^^^ ? | 15:09 |
| blasseye- | Yes it's in progress : https://review.opendev.org/c/openstack/keystone/+/985969 | 15:09 |
| blasseye- | Yes :) | 15:10 |
| tmazur | Thank you, I will add it to our etherpad | 15:10 |
| tmazur | Another SDK patch has been merged, thanks rdopiera and jjasek for your reviews! | 15:11 |
| tmazur | And I see all the listed de-angularization patches are also merged, great job everyone! | 15:12 |
| tmazur | omcgonag would you like to share with us if you currently working on some other de-angularization patch? | 15:13 |
| omcgonag | I have not yet picked up a new one, will let the team know which one I pick up | 15:14 |
| tmazur | Thank you! | 15:14 |
| omcgonag | thanks for the reviews and merge on the most recent ones... | 15:15 |
| tmazur | Let's move to the next topic | 15:15 |
| tmazur | #topic Bug deputy report | 15:16 |
| omcgonag | please put https://review.opendev.org/c/openstack/horizon/+/993023 on our etherpad - I need to get back to that one | 15:16 |
| tmazur | Is it related to de-angularization? | 15:18 |
| omcgonag | no - it is related to possibly addressing some of our random/flaky test/failures - I found it while running jobs against our deangularize patches | 15:21 |
| tmazur | Ok, thank you for the clarification | 15:21 |
| tmazur | Anyway, bugs | 15:21 |
| tmazur | https://bugs.launchpad.net/horizon/+bugs?orderby=-id&start=0 | 15:21 |
| tmazur | Openstack Security Note: OSSN-0097: Horizon RC file generation does not escape special characters in project names -- https://bugs.launchpad.net/horizon/+bug/2161336 | 15:22 |
| tmazur | This issue was fixed in https://bugs.launchpad.net/horizon/+bug/2152240 | 15:24 |
| tmazur | So I don't quite understand why the bug was filed | 15:24 |
| rdopiera | just mark it as duplicate? | 15:25 |
| tmazur | It even has the link to the fixed bug in references | 15:26 |
| rdopiera | we didn't fix it in stable releases | 15:27 |
| rdopiera | so I guess it's still an advisory | 15:27 |
| tmazur | In the description it says "master" | 15:27 |
| tmazur | Do we want to fix it in stables? | 15:27 |
| rdopiera | I don't, unless someone really wants it | 15:28 |
| tmazur | Let's mark this bug as duplicate until further notice then | 15:28 |
| rdopiera | it's more of an exposed sharp edge than actual security hole | 15:28 |
| tmazur | True | 15:29 |
| tmazur | One more bug | 15:29 |
| tmazur | Network topology icons and table sort carets blank after Font Awesome 6 migration -- https://bugs.launchpad.net/horizon/+bug/2161424 | 15:29 |
| tmazur | This one has a patch on review already | 15:30 |
| tmazur | 998121: Fix Font Awesome 4 leftovers missed by the FA6 migration | https://review.opendev.org/c/openstack/horizon/+/998121 | 15:30 |
| tmazur | I am testing it on my env now, should be good to go | 15:32 |
| tmazur | Next topic | 15:33 |
| tmazur | #topic On-demand agenda | 15:33 |
| tmazur | Let's discuss the possibility to catch some potential problems with requirements before they hit Horizon | 15:34 |
| tmazur | jjasek, I see you have added a patch on periodic job | 15:35 |
| tmazur | Would you like to share some info about it? | 15:35 |
| jjasek | Yep, but it is still WIP, I needed to jump to something else now. | 15:35 |
| jjasek | Yep, of course | 15:35 |
| jjasek | The goal is to periodically (once a day) go through all (lets say last x) opened patches in requirements | 15:36 |
| jjasek | and check if there are changes that could harm Horizon. And if yes, then fetch this patch and run horizon integration tests against this change | 15:37 |
| jjasek | Ideally we should know in advance that there is something in requirements, waiting for review that can break Horizon. And we can prepare Horizon or -1 the patch in requirements in case we are not able to do it quickly. | 15:37 |
| jjasek | And to not run the tests against many/all changes that are open in requirements. Goal is to fill this watchlist with everything that is used in Horizon: https://review.opendev.org/c/openstack/horizon/+/998068/5/playbooks/requirements-watch/files/watchlist.txt | 15:39 |
| jjasek | Currently there are packages that break Horizon (product or blocked gate) recently (last few quarters) | 15:40 |
| jjasek | That's all, very briefly, but it is still in WIP | 15:41 |
| tmazur | Shouldn't we add all the Horizon dependencies to the list? Do you think it's an overkill? | 15:42 |
| jjasek | I think that we can, theoretically, but the thing that I did not solved yet is rotation or runs. In case there will be multiple patches at once that can break horizon, and those patches will be there for days/weeks. | 15:43 |
| jjasek | I need to find some smart way to not run integration tests every day against 20 patches. | 15:44 |
| jjasek | (the same patches every day) | 15:44 |
| jjasek | Because as the changes are in requirements, ideally we should deploy fresh devstack for every single one I guess. | 15:44 |
| jjasek | So be sure there are no leftovers from other runs. | 15:45 |
| jjasek | But as I said, it is still WIP | 15:45 |
| rdopiera | I think zuul had a way to run tests for multiple patches, and then do binary search if they fail | 15:45 |
| rdopiera | I saw it in the docs | 15:46 |
| rdopiera | but I might have misunderstood | 15:46 |
| tmazur | I will look at it as well | 15:46 |
| jjasek | I got it but what I am talking about is some tracking. Because there can be 10 patches that touches horizon packages. And those patches can wait there for reviews months | 15:47 |
| jjasek | So it would be fine to find a way to somehow smart track what already was executed and if there is any change since. | 15:47 |
| jjasek | But as I said I spend a day on this, and yesterday night it was first time when it passed in Zuul :D | 15:49 |
| jjasek | So it is still in phase - what are possibilities. | 15:50 |
| tmazur | Thank you jjasek for your awesome work here | 15:51 |
| tmazur | Please ping the team if you need anything. It would be great to have this feature implemented | 15:52 |
| jjasek | Yep, when it will be in state that has some outlines and works, I will ask for reviews and we can discuss improvements/ideas/changes. | 15:53 |
| tmazur | Sure | 15:53 |
| tmazur | #topic Open reviews | 15:55 |
| tmazur | As usual, call for the reviews | 15:55 |
| tmazur | https://review.opendev.org/q/project:openstack/horizon+status:open | 15:55 |
| tmazur | We did a great job on reviews recently, let's keep the pace | 15:55 |
| tmazur | rdopiera would you like to say a few words about this one: | 15:57 |
| tmazur | 998096: Clean up after oslo.policy upgrade | https://review.opendev.org/c/openstack/horizon/+/998096 | 15:57 |
| tmazur | I see a couple +1 from oslo people | 15:58 |
| rdopiera | we also had some discussion in here earlier with tkajinam | 15:59 |
| rdopiera | I still want to hear from Ghanshyam, as he's the one leading that effort, it seems | 15:59 |
| tmazur | Makes sense, yes | 15:59 |
| tmazur | Anyway, we're out of time, let's wrap it up. Thanks everyone for joining today and see you next week! | 16:00 |
| rdopiera | the short story is that oslo.policy has removed the option to not do scope enforcement, and Horizon tests started failing, because we don't really care about scope for policy checks in horizon | 16:00 |
| tmazur | #endmeeting | 16:01 |
| opendevmeet | Meeting ended Wed Jul 22 16:01:04 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/horizon/2026/horizon.2026-07-22-15.00.html | 16:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/horizon/2026/horizon.2026-07-22-15.00.txt | 16:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/horizon/2026/horizon.2026-07-22-15.00.log.html | 16:01 |
| jjasek | Thank you all, bye bye | 16:01 |
| tmazur | rdopiera should we write to ML about it? | 16:02 |
| tmazur | Maybe more people will share their opinions | 16:02 |
| tmazur | Or just to inform that we're considering an options of vendoring it too | 16:03 |
| opendevreview | Merged openstack/horizon master: Fix Font Awesome 4 leftovers missed by the FA6 migration https://review.opendev.org/c/openstack/horizon/+/998121 | 18:51 |
| opendevreview | Vlad Gusev proposed openstack/horizon stable/2026.1: Fix Font Awesome 4 leftovers missed by the FA6 migration https://review.opendev.org/c/openstack/horizon/+/998358 | 19:04 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!