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