16:00:17 <gthiemonge> #startmeeting Octavia
16:00:17 <opendevmeet> Meeting started Wed Aug  7 16:00:17 2024 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:17 <opendevmeet> The meeting name has been set to 'octavia'
16:00:21 <gthiemonge> o/
16:00:31 <tweining> o/
16:00:34 <johnsom> o/
16:01:16 <gthiemonge> #topic Announcements
16:01:24 <gthiemonge> * 2024.2 Dalmatian Release Schedule
16:01:31 <gthiemonge> just a heads-up
16:01:39 <gthiemonge> Dalmatian-3 milestone is in 3 weeks (feature freeze)
16:01:50 <gthiemonge> we made good progress, the LB resize spec was merged
16:02:03 <gthiemonge> let's continue ;-) https://etherpad.opendev.org/p/octavia-priority-reviews
16:02:57 <tweining> well, a little progress I'd say
16:04:15 <tweining> something that slows progress really down if people don't follow up after updates IMO
16:06:04 <gthiemonge> you mean when you comment a review or when you update your reviews?
16:06:41 <tweining> I mean when someone updates the change after you commented you should review again soon
16:07:51 <johnsom> Our review backlog is pretty big, so I know it takes me a bit to come back around for re-reviews
16:08:27 <tweining> I don't want to sound like a broken record as I complained about it before, but I think it's also a good idea to keep an eye on changes that have a single CR+2
16:09:08 <johnsom> Looking at the review list, that isn't many....
16:10:15 <tweining> it's not many, but they are open for a long time.
16:11:39 <tweining> there are more annoncements, right?
16:12:35 <gthiemonge> I'll take a look at those patches
16:12:41 <gthiemonge> no tha'ts it
16:12:58 <gthiemonge> #topic New oslo.policy version
16:13:01 <gthiemonge> johnsom: ^
16:13:10 <tweining> I've read something about the upcoming election season on the ml
16:13:31 <gthiemonge> yeah I think it starts next week
16:13:42 <johnsom> So oslo.policy 4.4.0 is proposed for addition to upper-constraints.
16:13:52 <tweining> probably not relevant since Octavia has a BDFL already ;)
16:14:04 <johnsom> This version sets "new defaults" and "scope" to True by default.
16:14:39 <johnsom> The catch is "scope" to True will now cause any use of a system scoped token to be an Error
16:15:27 <johnsom> This is requiring some adjustments in unit and functional tests. With the latest patch posted, the unit tests are fixed, but functional tests are failing with 4.4
16:15:44 <johnsom> I'm not 100% sure why yet as it doesn't seem to be a scope problem.
16:16:12 <johnsom> For example, getting the quota defaults now fails with loadbalancer_member role, but passes with loadbalancer_admin.
16:16:28 <johnsom> I am working to track that down.
16:16:51 <johnsom> #link https://review.opendev.org/c/openstack/octavia/+/925532
16:17:09 <johnsom> This is the patch that resolves the unit tests (enough to unblock the UC merge)
16:17:53 <johnsom> This patch shows the functional issues: https://review.opendev.org/c/openstack/octavia/+/925625
16:18:31 <johnsom> That is the summary of the new SRBAC breakage/changes
16:19:04 <tweining> that doesn't sound like fun
16:19:17 <johnsom> I am just burned out dealing with this stuff frankly
16:19:22 <gthiemonge> johnsom: do you need help for these functional tests?
16:19:34 <johnsom> Not yet, let me keep poking at it
16:19:55 <gthiemonge> it's already late for me today, but I can take a look tomorrow morning
16:20:17 <johnsom> My current theory is this is causing the problems: https://github.com/openstack/octavia/blob/master/octavia/policies/base.py#L25
16:20:35 <johnsom> I.e. interactions with our Advanced RBAC and the "new defaults" changes
16:21:22 <johnsom> Well, those two "deprecated" rules
16:21:30 <gthiemonge> can we remove them?
16:21:35 <gthiemonge> deprecated since W
16:21:59 <johnsom> I think that 4.4 is essentially removing them and causing the failures
16:24:12 <gthiemonge> johnsom: please update me when you're done today, I may continue tomorrow
16:24:24 <johnsom> Ack
16:24:37 <gthiemonge> thanks for the update on this topic
16:25:20 <gthiemonge> I'm going to skip CI status: no update
16:25:25 <gthiemonge> #topic Brief progress reports / bugs needing review
16:25:50 <johnsom> Well, one item there is CentOS 9 Stream is broken with devstack due to missing rabbitmq RPMs
16:26:44 <gthiemonge> oh right
16:27:23 <gthiemonge> it's on devstack, right?
16:27:50 <johnsom> Yeah, devstack blows up
16:29:21 <gthiemonge> I'm wondering if it impacts rockylinux jobs
16:30:11 <johnsom> I don't know. I doubt it
16:32:40 <gthiemonge> https://zuul.opendev.org/t/openstack/builds?job_name=octavia-v2-dsvm-scenario-centos-9-stream&project=openstack/octavia
16:33:01 <gthiemonge> interesting, the package was succesfully installed 2 days ago
16:34:20 <gthiemonge> I'll try to follow up
16:34:27 <johnsom> Yeah, odd
16:35:03 <gthiemonge> FYI I proposed a fix for a bug in octavia-dashboard when using multi-region (with some multiple keystone instances)
16:35:09 <gthiemonge> https://review.opendev.org/c/openstack/octavia-dashboard/+/925672
16:36:02 <gthiemonge> I also proposed the new etcd jobboard plugin for Octavia
16:36:11 <gthiemonge> it includes a jobboard_etcd job in the experimental jobs
16:36:18 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/915834
16:36:53 <opendevreview> Merged openstack/octavia-dashboard master: Remove old excludes  https://review.opendev.org/c/openstack/octavia-dashboard/+/917600
16:38:17 <tweining> there is an indirect relation in the patch chain, so I guess the others in the chain need to be rebased
16:38:57 <opendevreview> Merged openstack/octavia-dashboard master: Bump hacking  https://review.opendev.org/c/openstack/octavia-dashboard/+/917601
16:39:12 <opendevreview> Gregory Thiemonge proposed openstack/octavia master: Update amphorav2/jobboard doc  https://review.opendev.org/c/openstack/octavia/+/923763
16:39:17 <gthiemonge> done
16:42:04 <gthiemonge> https://review.opendev.org/c/openstack/devstack/+/925400 was merged this morning, maybe it fixes the rabbitmq issue (devstack-platform-centos-9-stream passed)
16:42:51 <gthiemonge> #topic Open Discussion
16:42:56 <tweining> https://review.opendev.org/c/openstack/octavia/+/923318 should we talk about the rate limiting spec proposal?
16:43:14 <gthiemonge> yes
16:43:51 <gthiemonge> a few thoughts:
16:44:45 <gthiemonge> the octavia resources are usually created by passing the ID of their parents (a pool is attached to a listner, a listenr to LB, a l7policy to a listener, etc..)
16:45:10 <gthiemonge> in this spec, it's a bit different, the resource is created, then we need to call the listener api to add the resource to the listener
16:45:40 <gthiemonge> I'm wondering we should be more consistent and do something similar (create with parent)
16:46:00 <gthiemonge> note: pools can be created with or without parent, and associated with a listener later
16:46:49 <johnsom> Yeah, resources have to be tied to *something* for the correct project_id relationship, etc. That is why if a shared L7 policy is created unbound to the listener, it must be bound to the LB
16:46:51 <tweining> I don't have a strong opinion about that other than that it would be mainly a consistency issue it seems.
16:48:22 <tweining> that is a very good point then, because that is not the case with the proposal. the rules can be created independent from everything else
16:50:53 <gthiemonge> https://github.com/openstack/octavia/blob/master/octavia/api/v2/controllers/l7policy.py#L129
16:50:55 <johnsom> I guess I meant shared pools, not l7
16:51:09 <gthiemonge> yeah project_ids are inherited from the LB
16:51:43 <johnsom> The ID of the listener for the pool. Either listener_id or loadbalancer_id must be specified.
16:51:53 <johnsom> From the API ref
16:52:06 <johnsom> Yeah, l7 policy requires an listener ID
16:52:38 <tweining> well, the project_id is an attribute of the rule ATM. So I should change that to listener_id then I guess
16:53:14 <tweining> not sure if we should allow multiple listener_ids
16:53:22 <johnsom> Typically we want a project ID on all objects. It simplifies the RBAC and database queries
16:53:27 <gthiemonge> you can keep project_id, it's always included in user defined resources
16:54:29 <johnsom> Yeah, adding the listener ID the policy/rule is bound to is what I would expect to se
16:54:31 <johnsom> see
16:55:32 <tweining> does it make sense to you to share a rule with multiple listeners?
16:55:48 <johnsom> I don't see a reply to my last comment and I think there was a revision that dropped having split action and rule, is that correct? So you can't do "AND" rule logic anylonger?
16:56:44 <tweining> yeah, previously the action was part of a policy, which no longer exist. action is now part of the rule
16:57:34 <johnsom> Why would we limit the ability to do AND with multiple rules on a policy?
16:58:56 <tweining> if you have multiple rules they will still be ANDed AFAICT
16:59:54 <johnsom> That would be an OR right?
17:00:15 * johnsom maybe I need to get my second cup of coffee this morning
17:00:27 <tweining> ah, you AND in the sense that all rules need to be violated to it to rate limit
17:00:30 <tweining> *you mean
17:00:55 <tweining> mmh, honestly I never thought of it that way
17:01:09 <johnsom> Right, one policy "DROP" when BYTES AND REQUESTS exceed x
17:01:26 <johnsom> or x and y respectfully
17:01:50 <johnsom> That is how the l7 policies are setup I think
17:02:53 <tweining> ok, understood. I am not sure if such AND behavior can be done with HAProxy. I think it does OR normally
17:03:04 <gthiemonge> maybe we can describe some use cases in the review, and re-think about it
17:04:17 <tweining> +1 good idea
17:04:52 <johnsom> +1
17:05:05 <johnsom> use cases == tests. good stuff
17:05:32 <gthiemonge> ok, let's do that
17:05:47 <gthiemonge> anything else for today?
17:05:57 <tweining> not from me
17:06:11 <johnsom> https://docs.haproxy.org/dev/configuration.html#7.2
17:06:27 <johnsom> Nothing else from me this week
17:06:35 <tweining> thanks
17:07:00 <gthiemonge> ok! thank you guys!
17:07:04 <gthiemonge> #endmeeting