14:00:55 <haleyb> #startmeeting networking 14:00:55 <opendevmeet> Meeting started Tue Jan 9 14:00:55 2024 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:55 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:55 <opendevmeet> The meeting name has been set to 'networking' 14:01:07 <haleyb> hi everyone 14:01:10 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 14:01:20 <obondarev> hi 14:01:27 <slaweq> hi 14:01:28 <seba> hi 14:01:33 <ralonsoh> hello 14:01:34 <ykarel> o/ 14:01:51 <elvira> o/ 14:02:34 <haleyb> ralonsoh: thanks for leading meeting while i was away, is hard to get back to work :( 14:02:42 <mtomaska1> o/ 14:03:12 <haleyb> #topic announcements 14:03:15 <lajoskatona1> o/ 14:03:24 <haleyb> #link https://releases.openstack.org/caracal/schedule.html 14:04:00 <haleyb> this week is Caracal-2 milestone 14:04:28 <bcafarel> late o/ 14:04:51 <haleyb> i saw releases were proposed yesterday for neutron-lib and ovsdbapp 14:06:17 <haleyb> so we should keep merging features over the next month we want in the release 14:06:27 <haleyb> C-3 is week of Feb 26 14:06:52 <lajoskatona1> https://review.opendev.org/c/openstack/releases/+/904924 & https://review.opendev.org/c/openstack/releases/+/904943 are the release patches 14:07:11 <haleyb> lajoskatona1: thanks 14:07:57 <haleyb> any other announcements? i'm still working through my backlog and might have missed something 14:08:21 <ralonsoh> ussuri releases patch 14:08:31 <ralonsoh> https://review.opendev.org/c/openstack/releases/+/903294 14:08:37 <ralonsoh> this is still pending 14:09:47 <lajoskatona1> +1, I check this one also (also just back to work) 14:09:49 <haleyb> ralonsoh: ack, thanks, will take a look after meeting. those patches without FT can be ignored, we are working on a downstream solution for them 14:11:05 <haleyb> ok, lets move on 14:11:19 <haleyb> #topic bugs 14:11:24 <haleyb> elvira: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/EVBKX5NT7WMJ6II7QOVXKFU5APEHBKY2/ 14:11:36 <haleyb> from elvira^^ 14:12:31 <elvira> yes! There were only two bugs, and one of them is an RFE 14:13:23 <haleyb> ack, thanks, i will look at the RFE and add to drivers meeting 14:13:32 <haleyb> the other is unassigned 14:13:39 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2048198 14:13:49 <haleyb> neutron-lib role enforcer is writing warning messages 14:13:49 <ralonsoh> yeah this one was reported here in IRC 14:13:56 <ralonsoh> and I open this bug 14:14:22 <ralonsoh> this is not an "issue", this is not affecting the neutron enforcer 14:14:40 <ralonsoh> we should have a way to filter the rules to be loaded in the n-lib role enforcer 14:14:54 <ralonsoh> or at least to be able to no to check the rules loaded 14:15:03 <ralonsoh> but that requires a oslo.policy change 14:15:13 <ralonsoh> in any case, this is not an error 14:15:14 <ralonsoh> thanks 14:16:09 <haleyb> ralonsoh: ok, so from reading it is harmful but not impacting the neutron enforcer 14:16:25 <ralonsoh> no no, not harmful at all 14:16:28 <ralonsoh> just cosmetic 14:18:02 <haleyb> ah, ok, might just be me misunderstanding the wording 14:18:26 <elvira> ralonsoh: do you think this fits as low hanging fruit? 14:18:51 <ralonsoh> maybe but I don't think there is a trivial fix in neutron or oslo.policy 14:19:02 <elvira> oh ok :( 14:20:12 <haleyb> any other bugs to discuss? 14:20:46 <haleyb> this weeks deputy is slaweq, next week is me 14:21:22 <haleyb> moving on 14:21:37 <haleyb> #topic specs 14:21:42 <haleyb> #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open 14:21:58 <haleyb> so we still have 3 un-merged specs 14:22:15 <slaweq> I already started bug deputy this week :) 14:22:32 * slaweq is on different meeting in same time, sorry for delayed replies 14:22:49 <haleyb> slaweq: ack, thanks 14:22:53 <ralonsoh> I swear I'll spend time this week reviweing the specs 14:24:22 <haleyb> i'm worried there won't be time to get the actual work done, but maybe we can just focus on the OVN-IC one 14:24:32 <ralonsoh> sure 14:24:53 <ralonsoh> --> https://review.opendev.org/c/openstack/neutron-specs/+/891204 14:25:05 <haleyb> right 14:26:16 <haleyb> ok, moving on 14:26:32 <haleyb> #topic community_goals 14:27:16 <haleyb> lajoskatona1: with you just getting back as well assuming no changes in horizon status? 14:27:49 <lajoskatona1> I have to check my horizon patch is there is any comment, I just try to kill my email and chat backlog :-) 14:28:17 <lajoskatona1> https://review.opendev.org/c/openstack/horizon/+/891205 14:28:40 <haleyb> lajoskatona1: ack, thanks! 14:29:02 <lajoskatona1> As I remember some integration tests failed and finally I realized that it is most probably not gate issue (quite hard to find out from logs and reproduce locally for me at least) 14:29:24 <lajoskatona1> that's it for this topic 14:29:46 <haleyb> ok, glad it is progressing 14:30:35 <haleyb> #topic on_demand 14:31:01 <haleyb> i think the two items might be from last week, i did not have time to scrub this morning 14:31:34 <seba> at least for the fip gateway ip allocation issue, that was put in by me today 14:31:38 <haleyb> one was a change to python-neutronclient, which already has comments pointing in the right direction 14:32:14 <ralonsoh> haleyb, so you agree on this, right? 14:32:28 <ralonsoh> we should not add any new feature to neutronclient 14:32:35 <ralonsoh> even a new binding 14:33:08 <haleyb> ralonsoh: absolutely, as lajoskatona1 mentioned in the review it can go in the sdk code 14:33:20 <ralonsoh> perfect then (I added this topic) 14:33:49 <haleyb> seba: is there enough info in the comments for you to move forward? 14:33:49 <andreykurilin> Hi folks! So should neutronclient README be updated that it does not accept any new features? 14:33:57 <haleyb> doh, wrong comment 14:34:25 <ralonsoh> andreykurilin, yes, I'll push a patch with this information 14:34:40 <andreykurilin> thank you! 14:34:48 <lajoskatona1> +1, thanks ralonsoh 14:34:51 <haleyb> ralonsoh: thanks 14:35:24 <haleyb> second item was from seba 14:35:28 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/904783 14:36:05 <seba> yeah, so we basically need to decide if this bug is something that is relevant for upstream / other openstack installations or just in my environment 14:36:40 <ralonsoh> quick summary: now it is possible (for an admin) to assign a FIP with the GW IP 14:36:56 <ralonsoh> with the default policies (define the IP is allowed only to the admin) 14:37:03 <ralonsoh> this patch wants to prevent that 14:37:37 <seba> and it's also a changeable policy - in our OpenStack setup we allow the user to specify the ip for the fip they want to allocate 14:38:11 <haleyb> ralonsoh, right, we allow admin to do destructive things 14:38:12 <ralonsoh> IMO: as commented, this is (by default) an admin privilege and should be allowed if we want to have a VM as a GW proxy or firewall or something else 14:38:20 <seba> as I never would want an external gateway to be on the same ip as a fip (I'd rather unset the gateway of the external subnet) I'd go for completely forbidding this. 14:39:46 <ralonsoh> this could be an extension, no loaded by default of course 14:39:54 <ralonsoh> an API extension 14:40:11 <seba> or could be hidden behind a feature switch 14:40:31 <ralonsoh> no, we don't allow config driven API 14:40:49 <seba> okay 14:40:52 <lajoskatona1> +1 14:40:53 <haleyb> seba: i would agree with ralonsoh that we don't want to change the default behavior, but it could be an extension 14:40:55 <ralonsoh> any API behaviour is ruled by the API definitions and extensions 14:41:20 <ralonsoh> so, as commented, this could be a shim extension (empty extension) 14:41:33 <ralonsoh> and if loaded, then the API will react in the way you want 14:41:42 <seba> do you have an example for an api extension that is just loaded to add extra checks like this one? 14:41:57 <ralonsoh> I'll check that after the meeting 14:42:02 <seba> thanks 14:42:27 <seba> so, would such an extension be something that you'd be interested in having living in the upstream neutron codebase? 14:43:08 <ralonsoh> yes 14:43:14 <haleyb> we'll probably spend more time bike-shedding on the name :) 14:43:21 <seba> ha ;) 14:43:31 <seba> okay, sounds good 14:43:58 <haleyb> any other topics to discuss this week? 14:44:49 <haleyb> oh, is there a CI meeting today? 14:44:57 <ralonsoh> yes in 15 mins 14:45:05 <lajoskatona1> irc or video? 14:45:11 <ykarel> video 14:45:26 <lajoskatona1> thanks 14:45:38 <haleyb> thanks for attending everyone, will give you :15 back 14:45:48 <haleyb> #endmeeting