| opendevreview | Tobias Urdin proposed openstack/octavia master: Add service role allowed to list members in pool https://review.opendev.org/c/openstack/octavia/+/944884 | 08:24 |
|---|---|---|
| opendevreview | Tom Weininger proposed openstack/octavia master: Rate limiting support https://review.opendev.org/c/openstack/octavia/+/933016 | 12:19 |
| opendevreview | Tom Weininger proposed openstack/octavia master: Rate limiting support https://review.opendev.org/c/openstack/octavia/+/933016 | 14:33 |
| opendevreview | Tobias Urdin proposed openstack/octavia master: Add service role allowed to list members in pool https://review.opendev.org/c/openstack/octavia/+/944884 | 15:43 |
| gthiemonge | #startmeeting Octavia | 16:00 |
| opendevmeet | Meeting started Wed Mar 19 16:00:30 2025 UTC and is due to finish in 60 minutes. The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'octavia' | 16:00 |
| gthiemonge | o/ | 16:00 |
| johnsom | o/ | 16:00 |
| tweining_ | o/ | 16:00 |
| gthiemonge | #topic Announcements | 16:01 |
| gthiemonge | * 2025.1 Epoxy Release Schedule: R-2 | 16:01 |
| gthiemonge | octavia 16.0.0.0rc1 was released earlier this week | 16:01 |
| gthiemonge | it should be our final rc1 and then become 16.0.0 | 16:02 |
| gthiemonge | just in case, the deadline for additional RCs is next week | 16:02 |
| johnsom | Cool, so no critical open bugs at the moment? | 16:02 |
| gthiemonge | now that you're talking about it | 16:03 |
| gthiemonge | I'm wondering if https://review.opendev.org/c/openstack/octavia/+/944884 is a regression | 16:03 |
| johnsom | No, I don't think so, and I have some thoughts on this.... | 16:04 |
| gthiemonge | tobias-urdin: you may know better than us ^ | 16:04 |
| johnsom | I was going to bring this up in the open discussion section | 16:04 |
| gthiemonge | The "Today" in the commit message may indicate that it is new | 16:04 |
| johnsom | 1. It's implemented wrong, as there is no need to create a new rule, a role will work in that constants string. | 16:04 |
| johnsom | 2. Why can't Aodh use the new "reader" role added in the new keystone defaults? | 16:05 |
| tweining | that patch misses a launchpad bug btw | 16:05 |
| gthiemonge | hm I see | 16:05 |
| gthiemonge | so maybe it's not ready for Epoxy | 16:06 |
| gthiemonge | +1 tweining | 16:06 |
| gthiemonge | ok so definitly not a regression | 16:08 |
| gthiemonge | ack thanks | 16:08 |
| gthiemonge | another thing, about stable branches, I will propose stable releases for B C D, someone reported that a bug was not fixed in Bobcat. The patch is in the appropriate branch, but we haven't published a release | 16:10 |
| johnsom | +1, yeah that needs to happen | 16:10 |
| gthiemonge | any other announcements? | 16:12 |
| johnsom | Just a reminder to add topics to the PTG etherpad: | 16:12 |
| johnsom | #link https://etherpad.opendev.org/p/apr2025-ptg-octavia | 16:12 |
| gthiemonge | thanks! | 16:13 |
| gthiemonge | now, let's jump to | 16:14 |
| gthiemonge | #topic Brief progress reports / bugs needing review | 16:14 |
| gthiemonge | (I was on PTO, so no update from me) | 16:14 |
| tweining_ | I worked on the python-octaviaclient part of the rate limiting RFE in order to test the new API | 16:15 |
| johnsom | Mostly reviewing bugs and playing with performance testing | 16:15 |
| tweining_ | https://review.opendev.org/c/openstack/python-octaviaclient/+/944055 | 16:16 |
| tweining_ | everything is still WIP | 16:16 |
| gthiemonge | ack | 16:17 |
| gthiemonge | #topic Open Discussion | 16:19 |
| gthiemonge | anything else folks? | 16:19 |
| johnsom | I was just going to bring up that RBAC patch. I'm not sure it's the right approach to solving their problem. I don't think we need to change anything in Octavia IMO | 16:21 |
| gthiemonge | yeah as you mentioned, the new reader role has been designed for such cases | 16:22 |
| gthiemonge | johnsom: can you comment in the review? | 16:22 |
| tobias-urdin | i think it's just something that people haven't cared about | 16:22 |
| johnsom | Yep | 16:22 |
| tobias-urdin | aodh user install guide just says (like all other projects) to slap the global admin role on all service users | 16:22 |
| tobias-urdin | i'm doing inventory of all places we use admin role and try to work/investigate what changes is required/has been made upstream so far to support the secure RBAC goal | 16:23 |
| johnsom | tobias-urdin Given the new "reader" role in the new keystone defaults, wouldn't that be a good option? | 16:23 |
| tobias-urdin | to drop that and simply use service role or other role | 16:23 |
| tobias-urdin | johnsom: that can work yes, the only drawback i think is that we give a cloud-wide reader role, i.e the aodh user can read other resources such as servers, volumes etc, right? | 16:24 |
| johnsom | Yeah, in the TC RBAC goal, the "service" role is basically a clone of Admin given the wide requirements of the services | 16:24 |
| tobias-urdin | while using a global `service` role also has some sensitivity where it can perform some operations and ruin some things, it atleast cannot read all information everywhere | 16:24 |
| johnsom | Correct, this is one of the major down falls of the "secure RBAC" proposal. The advanced RBAC Octavia used to have was much more granular | 16:25 |
| tobias-urdin | yea, per-project roles is indeed more granular but doesn't give the overall feel of a unified cloud, as operators it has been pretty hard to integrate third party systems and keep up with all different roles that some projects have | 16:27 |
| johnsom | Would aodh be willing to use a custom role for Octavia. I.e. if we created "aodh-service" role by default? | 16:27 |
| tobias-urdin | it's indeed a very hard topic | 16:27 |
| tobias-urdin | i can't really speak for aodh, but as an operator using service would be the easiest because that would need to be assigned to all service users either way to allow their respective APIs to verify token against the keystone identity:validate_token policy | 16:29 |
| johnsom | Ok, let me think about this some. The service role can create/delete ports in neutron, etc. so basically "admin". | 16:31 |
| tobias-urdin | yeah, the biggest win is that only having the service role you cannot retrieve info about all exactly all resources, or perform actions such as delete instances, delete volumes etc causing major dataloss | 16:32 |
| tobias-urdin | let me know what you come up with :) | 16:33 |
| gthiemonge | ok folks, I think that's all for this week | 16:36 |
| gthiemonge | thanks for raising this topic BTW | 16:36 |
| gthiemonge | have a good week guys! | 16:37 |
| gthiemonge | #endmeeting | 16:37 |
| opendevmeet | Meeting ended Wed Mar 19 16:37:28 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:37 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/octavia/2025/octavia.2025-03-19-16.00.html | 16:37 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/octavia/2025/octavia.2025-03-19-16.00.txt | 16:37 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/octavia/2025/octavia.2025-03-19-16.00.log.html | 16:37 |
| tobias-urdin | thanks! have a nice rest of the week | 16:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!