16:00:39 <gthiemonge> #startmeeting Octavia
16:00:39 <opendevmeet> Meeting started Wed Jul 10 16:00:39 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:39 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:39 <opendevmeet> The meeting name has been set to 'octavia'
16:00:43 <gthiemonge> o/
16:00:46 <johnsom> o/
16:00:51 <tweining> o/
16:00:54 <damiandabrowski> hi!
16:01:23 <gthiemonge> #topic Announcements
16:01:42 <gthiemonge> well, no annoucements from me this week
16:01:53 <johnsom> Nothing from me either
16:02:18 <tweining> let's move on then
16:02:46 <gthiemonge> we passed Dalmatian-2, the next milestone is the final release for non-client libraries (Aug 19) then the week after is the Feature Freeze
16:03:06 <gthiemonge> I'll skip CI status too, no update
16:03:11 <gthiemonge> #topic Brief progress reports / bugs needing review
16:03:29 <gthiemonge> FYI the new etcd backend for taskflow jobboard merged earlier this week
16:03:39 <gthiemonge> now we need a plugin in octavia to use it
16:03:59 <johnsom> I have been working on reviews.
16:04:09 <gthiemonge> I'm working on it but I found a bug in etcd3gw (I proposed a fix), so it means that we will need a release of taskflow (for the etcd backend) and etcd3gw (for the fix) before approving my patch
16:04:20 <gthiemonge> thanks for the reviews guys
16:04:41 <johnsom> I also posted some patches for issues in the Octavia devstack plugin when running on Ubuntu 24.04 (related to some SR-IOV testing work I have)
16:05:37 <tweining> https://review.opendev.org/c/openstack/octavia/+/923318 I updated the rate limiting spec. Thanks for your comments. It really helps to have different views.
16:06:16 <johnsom> Yeah, I got to a few of the specs, I still have two more on the review pile
16:06:21 <tweining> I have one question about the "notifications impact" section. Is it about event notifications https://docs.openstack.org/octavia/latest/admin/event-notifications.html
16:07:11 <johnsom> Yes
16:07:30 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/923318/comment/6b6187bb_28443eb1/
16:07:43 <gthiemonge> johnsom: do you expect new notifications with this feature?
16:08:13 <gthiemonge> right now we only have notifications for the creation/update/deletion of the LBs
16:08:31 <johnsom> Well, it adds two new API endpoints with Create/Update/Delete methods. So I would expect notifications to be generated for them, meaning there will be new notifications
16:09:36 <johnsom> I don't know how much special code there would be for that, but at a minimum we will be sending new notifications.
16:09:40 <tweining> hmm, I will need to look into that. It wasn't on my radar until now.
16:10:13 <gthiemonge> it's not a huge task
16:10:27 <johnsom> Hmm, do we only send them for LB create/update/delete? I thought we sent them for all of the API endpoints.
16:10:45 <gthiemonge> nop
16:10:49 <gthiemonge> https://opendev.org/openstack/octavia/src/branch/master/octavia/controller/worker/v2/tasks/notification_tasks.py
16:11:22 <johnsom> Ok, then I was remembering it wrong. Disregard my notifications comment.
16:11:23 <gthiemonge> I think we can specify the notifications in the spec, but I feel that we don't need to implement them now
16:11:41 <tweining> ok
16:11:43 <johnsom> (designate sends them for everything, so I am probably just getting the projects mixed)
16:11:48 <gthiemonge> yeah notifications are limited
16:11:52 <gthiemonge> haha
16:12:04 <gthiemonge> we can improve the notifications in Octavia ;-)
16:13:25 <johnsom> I have also looked into the IPv6 test failures. This is an interesting ordering thing.
16:13:55 <johnsom> Does anyone remember why we had to remove the gateway address from the lb-mgmt-net when the ML2 is OVN?
16:14:00 <noonedeadpunk> o/
16:14:18 <johnsom> I seem to remember it was some OVN bug, but a quick search didn't bring it up.
16:14:31 <gthiemonge> johnsom: I remember something about ARP requests sent to an non-existant gateway
16:14:49 <johnsom> #link https://github.com/openstack/neutron/blob/master/devstack/lib/octavia#L14
16:15:44 <gthiemonge> johnsom: maybe related to https://bugzilla.redhat.com/show_bug.cgi?id=1961162
16:16:41 <johnsom> So, if we remove the gateway all of the time to address this ordering bug, we have to remove the router from the network too, which means SLAAC and probably DHCP don't work anymore.
16:17:33 <johnsom> Unless OVN doesn't have that limitation and it was only OVS/linux bridge
16:17:51 <gthiemonge> I need to check but the IP address of the management interface might be static in most of cases
16:18:40 <noonedeadpunk> I can distantly recall some backport in neutro regarding broadcast flood for OVN... but really vaguely, so might be not related...
16:18:42 <johnsom> Yeah, I kind of thing so too. I may go down that path of removing the router too. My patch yesterday removes the DHCP from the o-hm0 interface.
16:19:30 <johnsom> cloud-init should "do the right thing" in the amp instances without DHCP
16:19:54 <noonedeadpunk> maybe it was https://bugs.launchpad.net/neutron/+bug/2069625... but not sure
16:21:38 <noonedeadpunk> sorry folks, would there be an open discussion? As I failed to find a meeting agenda recently and have something to raise
16:22:07 <gthiemonge> noonedeadpunk: please go ahead
16:22:34 <noonedeadpunk> yeah, so that;'s the topic I've raised couple of PTGs ago and you pretty much aware about - AZs :D
16:22:56 <gthiemonge> yeah i've seen some updates in gerrit :)
16:23:00 <noonedeadpunk> I tried to make a different approach and target changes to nova scheduling groups
16:23:14 <noonedeadpunk> and then arddennis also proposed the blueprint: https://review.opendev.org/c/openstack/octavia/+/923571
16:23:29 <noonedeadpunk> as during implementation it appears that multiple options are possible
16:23:47 <noonedeadpunk> so I thought that it's best to have it written for futher discussion
16:24:17 <noonedeadpunk> basically, we're having implementation mostly ready, except unsure about couple of points described in the blueprint
16:25:09 <noonedeadpunk> frankly - I kinda like doing thing on a nova side. Though there was quite some level of complexity in how scheduler works with regards to AZs
16:25:48 <noonedeadpunk> or better say ordering of data, as AZ was passed to filters directly...
16:26:49 <noonedeadpunk> TL;DR - once you have a spec review day - ping me or arddennis for some discussion around this
16:27:04 <arddennis> Maybe the main point. If compute_tasks is a good place to distribute amphora instances across AZ. Maybe there should be AZ defined for each amphora inside worker?
16:27:08 <noonedeadpunk> as there're outstanding questions in spec
16:27:31 <johnsom> It is one of the next specs on my list to review
16:27:40 <gthiemonge> noonedeadpunk: ack, I will review it in the next days (maybe this week)
16:27:41 <johnsom> That and re-review the resize one
16:28:13 * noonedeadpunk very sorry for us taking _that_ long to get any progress
16:28:21 <gthiemonge> BTW I like to read the rendered doc, but it doesn't look alright https://d2cee1cf1f9910cb6506-7163d5c589c56aef778972593b9aaf7c.ssl.cf2.rackcdn.com/923571/7/check/openstack-tox-docs/350a8d5/docs/contributor/specs/version15.0/multiaz_amphora_distribution.html
16:28:55 <noonedeadpunk> ah, yes, will fix that right away
16:29:27 <gthiemonge> thanks
16:30:40 <gthiemonge> noonedeadpunk: are the unclear points highlighted in the spec?
16:31:14 <noonedeadpunk> arddennis: ^
16:31:26 <arddennis> It is described in Alternatives
16:32:38 <gthiemonge> (I added it to our priority review etherpad: https://etherpad.opendev.org/p/octavia-priority-reviews)
16:32:40 <arddennis> It looks like controller_worker is a better place than compute_tasks. But I am deeply unsure if it is a good path either
16:33:20 <gthiemonge> ok I see
16:33:21 <noonedeadpunk> gthiemonge: I _think_ we can also propose our WIP on top of the spec.
16:34:04 <noonedeadpunk> potentially it might be easier for you to grasp some spec parts with it...
16:34:18 <noonedeadpunk> (with code implementing that)
16:34:24 <noonedeadpunk> s/that/spec
16:34:29 <gthiemonge> yeah that sounds good to me
16:36:06 <noonedeadpunk> ok, agred then
16:36:48 <gthiemonge> great!
16:37:44 <noonedeadpunk> we'll try to do that asap so you could have a review later this week if have time for that :D
16:38:23 <gthiemonge> anyways, I can take a look at the spec in its current form
16:39:40 <noonedeadpunk> sure, thanks! sorry for hijacking the meeting
16:40:15 <gthiemonge> hey np
16:40:15 <tweining> I have nothing else to talk about today
16:40:29 <gthiemonge> any other topics for today?
16:41:17 <gthiemonge> ok!
16:41:24 <gthiemonge> then, Have a good week!
16:41:30 <gthiemonge> thank you folks
16:41:33 <gthiemonge> #endmeeting