| gouthamr | https://bugs.launchpad.net/manila/+bug/2167305 is now public | 06:50 |
|---|---|---|
| opendevreview | OpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals https://review.opendev.org/c/openstack/security-doc/+/1007456 | 11:34 |
| opendevreview | Merged openstack/security-doc master: Updated from openstack-manuals https://review.opendev.org/c/openstack/security-doc/+/1007456 | 11:46 |
| fungi | https://bugs.launchpad.net/neutron/+bug/2167791 is now public | 13:25 |
| fungi | https://bugs.launchpad.net/octavia/+bug/2168430 is now public | 13:41 |
| *** bauzas5 is now known as bauzas | 13:44 | |
| tkajinam | gouthamr, I wonder if you can vote PTL-approved on behalf of Hao to https://review.opendev.org/c/openstack/releases/+/1007274 to get rc2 released ? | 13:55 |
| tkajinam | and https://review.opendev.org/c/openstack/releases/+/1007406 for stable releases | 13:55 |
| tkajinam | I'm unsure if Hao would be able to check it timely... I probably should ask him to add me as a release liaison | 13:55 |
| fungi | tkajinam: i can | 13:57 |
| fungi | i'm probably going to need to do so for a swift release request today too | 13:57 |
| fungi | i'll do it after the release team meeting wraps up | 13:58 |
| tkajinam | fungi, thanks ! | 13:58 |
| fungi | yw | 13:58 |
| fungi | thanks for getting that lined up! | 13:58 |
| fungi | https://bugs.launchpad.net/barbican/+bug/2168427 is now public | 16:06 |
| fungi | xek suggested an ossn could be warranted for https://bugs.launchpad.net/ossn/+bug/968696 | 16:13 |
| gouthamr | xek: fungi: would a security note be the right place? it seems like we need long living documentation for this - curated by the Keystone team | 17:23 |
| gouthamr | we've got a few documents regarding RBAC that hurt everyone's brain to put together :| we have this TC goal: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html | 17:23 |
| gouthamr | this keystone doc: https://docs.openstack.org/keystone/latest/admin/service-api-protection.html | 17:23 |
| fungi | i think that's fine as long as the current situation is documented somewhere visible/easily discoverable so that we can stop confusing people about whether it makes sense to set the "admin" role in a project | 17:26 |
| gouthamr | ack, i'll try and get gmaan's attention to this too. there's interest to drive the "admin" discussion forward, then there's the aspect of completing the TC goal as is written and getting that documented (don't know if cardoe volunteered for the latter or the former) | 18:28 |
| * gouthamr adding an item to the TC's PTG etherpad about this | 18:28 | |
| cardoe | That bug report is absolutely something that I've trying to bring up on the ML | 18:29 |
| cardoe | And come up with something moving forward. | 18:29 |
| gouthamr | yeah, now that we're past a release, it's a good time to carve some time out for this? :) | 18:30 |
| cardoe | I've proposed some "user stories" around what each role can be used for. | 18:30 |
| cardoe | I know keystone has some of this already and there's some confusion there. | 18:30 |
| fungi | i think so. it's been a thorn in the vmt's side for many years and i'm sure we're not the only ones annoyed by it | 18:30 |
| cardoe | I've proposed a couple of things and I know the keystone PTL wants to rewrite how all that policy and such work. | 18:31 |
| gouthamr | for sure, think of the users/operators | 18:31 |
| cardoe | gouthamr: exactly | 18:31 |
| cardoe | That's who my focus is. | 18:31 |
| cardoe | I don't think a TC meeting is the best forum though. | 18:32 |
| cardoe | We need to session to collect what are the bad and what are the good. | 18:32 |
| cardoe | And then a brain storming session | 18:32 |
| fungi | an ops session? a keystone session? srbac pop-up team? | 18:33 |
| cardoe | not a keystone session | 18:34 |
| cardoe | Or at least there's a big differing of opinions here | 18:34 |
| cardoe | Basically it cannot be solved with keystone v3 and must be v4. All projects must adopt v4 first. | 18:35 |
| fungi | i'm just wondering what group(s) of people you want in the discussion if not the tc | 18:36 |
| cardoe | I want the TC. I'm saying not in the middle of a regular TC meeting | 18:36 |
| fungi | oh, you said tc meeting, gouthamr said tc ptg session | 18:37 |
| fungi | i guess that's where i got confused | 18:37 |
| cardoe | yeah tc ptg session would be great | 18:37 |
| gouthamr | yes, teh tc can help organize efforts or amplify a wider problem, we won't solve the problem in isolation ofc.. i meant to use the PTG session just to do that | 18:38 |
| fungi | i totally agree this is a ptg discussion not a tc meeting agenda topic | 18:38 |
| gouthamr | fungi: JayF: i've also added this: https://etherpad.opendev.org/p/oct2026-ptg-os-tc#L70 - would be of interest to you as well. I don't want it to be a discussion without consequence though, i'll try and get some movement on it | 18:38 |
| gouthamr | scalpel fixes happened throughout the release | 18:38 |
| cardoe | So for my first proposal, clouds.yaml entry can be scoped to multiple scopes. I think that would solve the past operator problems with using system/project scope. | 18:38 |
| fungi | yes, driving the tc toward more actionable decisions (doesn't mean the tc members need to be the ones taking on those actions) would be a great outcome | 18:39 |
| cardoe | I've been changing around keystoneauth and openstacksdk to grab the unscoped token and then grab the correct scope to do the operations | 18:39 |
| cardoe | lemme share a rough draft patch | 18:39 |
| JayF | I will say, if the "solution" involves "changing what RBAC things mean for a third (or at least 2nd and a half) time" then I am -1 as strong as possible | 18:42 |
| gouthamr | i don't expect to change this in its entirety. I'm hoping the change is incremental | 18:43 |
| JayF | I feel like I can barely keep my mind wrapped around our RBAC model, and I work on the project. How can operators keep a consistent view when we haven't been consistent (non-atomic migration + scope additions after launch) | 18:43 |
| JayF | incremental change is still cognitive load | 18:43 |
| gouthamr | yes, but, only if you want to unlock a capability we don't currently have (which causes all of this misunderstanding) | 18:43 |
| cardoe | So I agree with you guys | 18:45 |
| cardoe | https://review.opendev.org/c/openstack/openstacksdk/+/1007536 | 18:45 |
| cardoe | That's the draft patch I'm talking about. | 18:45 |
| cardoe | I've also proposed splitting things a little bit at the system scope level | 18:45 |
| cardoe | Right now only "all" is valid. | 18:45 |
| cardoe | I've proposed that every registered service is valid as well | 18:46 |
| cardoe | And "all" is an alias for them all | 18:46 |
| cardoe | So one could have "neutron:reader" and "ironic:member" as a system scope | 18:47 |
| cardoe | Today it's "all:reader" or "all:member" or "all:admin" | 18:47 |
| cardoe | I do think we have a problem with "global" and "system" | 18:49 |
| cardoe | Because I think "system scope" should operate on non-project level resources and public=True resources | 18:49 |
| cardoe | So for example an image inside of glance that's public=True | 18:49 |
| cardoe | Should the project admin mess with that? | 18:49 |
| cardoe | I feels like it should really be removed out of the project scope at that point. | 18:50 |
| cardoe | But then there's also the case where if we do that then "system scope" shouldn't mean "touch every project" | 18:50 |
| fungi | yeah, i've in principle been in favor of the suggestion that system-level permissions be completely disjoint from tenant/project permissions, maybe as if system is another tenant on its own even | 18:50 |
| cardoe | Which brings back a "global admin" type thing to touch every project. | 18:50 |
| cardoe | Which I would also want a "global audit". I actually want the "audit" role to have less view on resources than the reader role. | 18:51 |
| cardoe | So if you look at barbican... I want a global auditor that can say this credential is secured with algorithm X or maybe it was last updated at Y time. And the auditor can validate that policies are enforced but the auditor shouldn't be able to read the contents. | 18:51 |
| cardoe | But this gets back to wanting to hear the good / bad and craft some actual operator oriented use cases for how our services should work. | 18:52 |
| fungi | so it keeps sounding like this should be a session (or associated with a session) where we try to get some operator voices in the discussion | 18:53 |
| fungi | i know ildikov has been trying to put together operator feedback topics for the ptg already | 18:53 |
| gouthamr | yeah, agreed.. | 18:53 |
| gouthamr | was just pulling up the link | 18:54 |
| gouthamr | https://etherpad.opendev.org/p/ops-devs-qanda-2026 | 18:54 |
| cardoe | gouthamr: I just need ya to block off TC time with me on my calendar where we write up some goals and actionable items otherwise I forget. :-D | 18:54 |
| * gouthamr proceeds to block 9-9-6 on cardoe's calendar | 18:55 | |
| * gouthamr shows himself out for that joke.. | 18:56 | |
| * JayF hands gouthamr a "cardoe, you'd be able to achieve your goals more successfully as vice-chair" ;) | 18:58 | |
| fungi | ah, the prc tech working hours | 18:58 |
| gouthamr | JayF: what a wonderful idea :P | 18:58 |
| gouthamr | fungi: we're not immune out here: https://www.wired.com/story/silicon-valley-china-996-work-schedule/ | 18:59 |
| fungi | indeed | 18:59 |
| JayF | I'm immune to it. The word "no" is immune to it. | 18:59 |
| JayF | Working 72 hours a week is a great way to produce a lot of low-quality stuff. | 19:00 |
| JayF | Hey, I bet these are the same folks who think LLMs are great ;) | 19:00 |
| fungi | being able to say "no" (and then get shown the door for some made-up employment agreement violation) is a privilege some people are not afforded, sadly | 19:02 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily while we upgrade to a new patch release, but should return within a few minutes | 19:04 | |
| *** mrunge_ is now known as mrunge | 23:54 | |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!