16:00:03 #startmeeting Octavia 16:00:03 Meeting started Wed Jul 31 16:00:03 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:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:03 The meeting name has been set to 'octavia' 16:00:05 o/ 16:00:07 o/ 16:00:14 o/ 16:01:30 #topic Announcements 16:01:35 * 2024.2 Dalmatian Release Schedule 16:01:42 The feature freeze is in 4 weeks 16:01:51 https://etherpad.opendev.org/p/octavia-priority-reviews 16:02:17 please prioritize spec and feature patches! 16:03:23 +1, we have some SR-IOV patches still open, including some that need to be backported 16:03:48 we have lots of patches still open 16:04:24 we also need to get better at following up after patches were updated 16:05:17 In other announcements, some stable branch releases have been proposed 16:05:42 Also, the foundation has student groups available for projects if anyone is interested in mentoring some students. 16:06:01 right, and antelope will be unmaintained soon 16:06:50 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/62AGYQRPDWANS377DLSU7Q7TLNDNXPAK/ 16:07:12 good that Red Hat will start maintaining right in time then ;) 16:07:30 *downstream of course 16:09:26 any other announcements? 16:10:15 no, only that we didn't meet our goal from last week 16:10:20 Oh, the "E" series schedule has been announced as well 16:10:56 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/V3TU7EZ7QYHI2N57YG35RVUIOAMGDBKY/ 16:11:06 I mean to integrate at least one spec patch. but there were some reviews at least 16:13:02 yeah I have updated the SG on VIPs spec after Michael's feedback, now I'll look at yours 16:14:27 #topic CI Status 16:14:33 an update here! 16:14:51 The fix for the IPv6 tempest job merged today! 16:14:59 thank you johnsom! 16:15:06 +1, good to have that running again 16:16:48 gthiemonge: https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/921402 (and the follow-up patch) still need approval 16:18:06 +1 16:18:08 right 16:19:49 #topic Brief progress reports / bugs needing review 16:20:25 I have been working on a path to be able to test SR-IOV in the zuul gates. 16:20:27 I have nothing else for today. 16:20:58 It's not clear if opendev will be able to have nodepool instances with the right qemu driver in them due to the clouds that provide the resources. 16:21:34 The alternative would be to nest devstack one VM layer deeper, which is not ideal 16:22:05 I agree, more overhead 16:22:36 When I set this up local, the igb driver provides 7 VFs by default, which I think will work nicely for the tests. 16:22:55 Most real nics provide up to 255, fyi 16:25:34 interesting! 16:30:16 #topic Open Discussion 16:30:47 I would like to talk about this patch that came in this morning: 16:30:49 #link https://review.opendev.org/c/openstack/octavia/+/925327 16:31:37 yeah I saw it 16:32:06 I have concerns about adding third-party provider driver code to the main repository. 16:32:39 it's related to https://review.opendev.org/c/openstack/ovn-octavia-provider/+/925324 16:32:45 Looking at the code, it is accessing Octavia internals and the database 16:32:56 I agree 16:33:06 Most of it is Octavia related code, with one line that ties it specifically to OVN 16:33:34 I think they're trying to avoid a limitation of the octavia_lib api: retrieving the list of LBs 16:34:15 mmh, it's still W-1 so wouldn't even take notice of it normally 16:35:41 johnsom: do you want to leave a comment about that? 16:36:25 Well, I was trying to decide what comment to leave.... 16:36:45 Option 1, this should go in the OVN provider repo 16:36:57 Option 2, it should be made driver agnostic 16:37:25 Option 3, if you need a list of your own LBs, why can't you query the Octavia API? 16:37:32 for 1. I think the ovn provider cannot import Octavia modules directly 16:37:46 * johnsom notes, option 3 is documented in the driver developer guide 16:38:10 This is true, the provider should not for sure 16:38:48 yeah mixing Octavia API and octavia_lib is possible 16:40:52 The other issue with that patch is it's creating a new provider driver method that doesn't exist today 16:41:12 I.e. isn't documented, isn't in the base class, etc. 16:42:47 so I would be in favor of Option 3. Option 2 is also possible but I'm not sure it would be useful for other provider drivers 16:43:20 One could argue that if one driver needs it, others might too 16:43:43 it's a WIP patch, but in order to be proposed they would need to add the method to the driver framework 16:44:12 For sure. 16:44:12 if you're concerned, maybe we should comment that this should be discussed further either here or on the mailing list 16:44:24 I just wanted to start a discussion about this 16:44:35 I would prefer option 3 as well BTW, because it seems to have the least impact 16:45:32 option 3 would be more backportable too 16:45:37 It also means less DB code to maintain 16:47:56 Ok, I think I have enough thoughts and input to comment on the patch 16:48:06 Thank you for the discussion 16:48:09 thanks johnsom 16:49:36 do you have any other topics? 16:49:46 I don't 16:50:04 I already said that I don't either 16:50:11 ok! 16:50:16 thank you guys! 16:50:24 #endmeeting