16:00:30 <gthiemonge> #startmeeting Octavia
16:00:30 <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:30 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:30 <opendevmeet> The meeting name has been set to 'octavia'
16:00:34 <gthiemonge> o/
16:00:35 <johnsom> o/
16:00:57 <tweining_> o/
16:01:17 <gthiemonge> #topic Announcements
16:01:29 <gthiemonge> * 2025.1 Epoxy Release Schedule: R-2
16:01:50 <gthiemonge> octavia 16.0.0.0rc1 was released earlier this week
16:02:14 <gthiemonge> it should be our final rc1 and then become 16.0.0
16:02:34 <gthiemonge> just in case, the deadline for additional RCs is next week
16:02:38 <johnsom> Cool, so no critical open bugs at the moment?
16:03:17 <gthiemonge> now that you're talking about it
16:03:50 <gthiemonge> I'm wondering if https://review.opendev.org/c/openstack/octavia/+/944884 is a regression
16:04:12 <johnsom> No, I don't think so, and I have some thoughts on this....
16:04:23 <gthiemonge> tobias-urdin: you may know better than us ^
16:04:26 <johnsom> I was going to bring this up in the open discussion section
16:04:47 <gthiemonge> The "Today" in the commit message may indicate that it is new
16:04:59 <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:05:25 <johnsom> 2. Why can't Aodh use the new "reader" role added in the new keystone defaults?
16:05:50 <tweining> that patch misses a launchpad bug btw
16:05:57 <gthiemonge> hm I see
16:06:18 <gthiemonge> so maybe it's not ready for Epoxy
16:06:23 <gthiemonge> +1 tweining
16:08:04 <gthiemonge> ok so definitly not a regression
16:08:21 <gthiemonge> ack thanks
16:10:21 <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:41 <johnsom> +1, yeah that needs to happen
16:12:09 <gthiemonge> any other announcements?
16:12:43 <johnsom> Just a reminder to add topics to the PTG etherpad:
16:12:45 <johnsom> #link https://etherpad.opendev.org/p/apr2025-ptg-octavia
16:13:30 <gthiemonge> thanks!
16:14:00 <gthiemonge> now, let's jump to
16:14:06 <gthiemonge> #topic Brief progress reports / bugs needing review
16:14:28 <gthiemonge> (I was on PTO, so no update from me)
16:15:40 <tweining_> I worked on the python-octaviaclient part of the rate limiting RFE in order to test the new API
16:15:42 <johnsom> Mostly reviewing bugs and playing with performance testing
16:16:01 <tweining_> https://review.opendev.org/c/openstack/python-octaviaclient/+/944055
16:16:11 <tweining_> everything is still WIP
16:17:44 <gthiemonge> ack
16:19:28 <gthiemonge> #topic Open Discussion
16:19:50 <gthiemonge> anything else folks?
16:21:01 <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:22:10 <gthiemonge> yeah as you mentioned, the new reader role has been designed for such cases
16:22:19 <gthiemonge> johnsom: can you comment in the review?
16:22:44 <tobias-urdin> i think it's just something that people haven't cared about
16:22:48 <johnsom> Yep
16:22:58 <tobias-urdin> aodh user install guide just says (like all other projects) to slap the global admin role on all service users
16:23:31 <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:33 <johnsom> tobias-urdin Given the new "reader" role in the new keystone defaults, wouldn't that be a good option?
16:23:47 <tobias-urdin> to drop that and simply use service role or other role
16:24:24 <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:34 <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:58 <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:25:28 <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:27:33 <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:34 <johnsom> Would aodh be willing to use a custom role for Octavia. I.e. if we created "aodh-service" role by default?
16:27:43 <tobias-urdin> it's indeed a very hard topic
16:29:41 <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:31:35 <johnsom> Ok, let me think about this some. The service role can create/delete ports in neutron, etc. so basically "admin".
16:32:52 <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:33:52 <tobias-urdin> let me know what you come up with :)
16:36:17 <gthiemonge> ok folks, I think that's all for this week
16:36:24 <gthiemonge> thanks for raising this topic BTW
16:37:23 <gthiemonge> have a good week guys!
16:37:28 <gthiemonge> #endmeeting