14:06:23 <lajoskatona> #startmeeting networking
14:06:23 <opendevmeet> Meeting started Tue Feb 15 14:06:23 2022 UTC and is due to finish in 60 minutes.  The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:06:23 <opendevmeet> The meeting name has been set to 'networking'
14:06:27 <mlavalle> o/
14:06:31 <lajoskatona> Hi, sorry for being late
14:06:35 <ralonsoh> hi
14:06:37 <obondarev> hi
14:06:39 <bcafarel> o/
14:06:39 <isabek_> Hi
14:07:17 <lajoskatona> #topic Announcements
14:07:23 <gibi> o/
14:07:26 <dmitriis> o/
14:07:26 <slaweq> hi
14:07:32 <lajoskatona> first and most important: Z name is Zed: http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027242.html
14:07:32 <haleyb> hi
14:07:43 <opendevreview> Balazs Gibizer proposed openstack/neutron master: Show port MAC from binding profile for PFs  https://review.opendev.org/c/openstack/neutron/+/829247
14:07:53 <rubasov> o/
14:08:15 <bcafarel> that sounds to me as the "Pulp Fiction" release :)
14:08:21 <fnordahl> lol
14:08:30 <obondarev> haha
14:08:34 <lajoskatona> bcafarel: yes it seems that it will be
14:09:06 <lajoskatona> A few release patches for libs around networking:
14:09:12 <lajoskatona> n-lib release: https://review.opendev.org/c/openstack/releases/+/829078
14:09:17 <lajoskatona> ovsdbapp: https://review.opendev.org/c/openstack/releases/+/829101
14:09:21 <lajoskatona> os-ken release: https://review.opendev.org/c/openstack/releases/+/829083
14:09:46 <lajoskatona> please check them and raise your hand if you feel that something is missing, as this will be the final Yoga release for them
14:10:11 <slaweq> lajoskatona deadline is this week, right?
14:10:25 <lajoskatona> slaweq: yes, 17 February I think
14:10:29 <slaweq> ok, thx
14:11:10 <lajoskatona> Actually no more announcements from me
14:11:19 <lajoskatona> Do you have questions?
14:11:51 <lajoskatona> #topic Bugs
14:11:56 <mlavalle> I was hoping for Zorro
14:12:00 <lajoskatona> Report from bcafarel: http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027224.html
14:12:20 <lajoskatona> mlavalle: I liked Zomicron, but we have to leave with Zed now
14:12:34 <bcafarel> :)
14:12:53 <lajoskatona> bcafarel: Do you have anything to highlight from last week's bugs?
14:13:05 <slaweq> lajoskatona Zomicron seems nice but may be too suggestive :)
14:13:21 <lajoskatona> :-)
14:13:25 <bcafarel> quickly checking on updates but it was overall quiet week
14:13:51 <bcafarel> https://bugs.launchpad.net/neutron/+bug/1960533 looks like a nice low-hanging fruit to fix (but no urgency)
14:14:09 <bcafarel> others are in good shape (fix or someone looking into it)
14:14:39 <lajoskatona> Thanks bcafarel
14:15:43 <lajoskatona> This week slaweq is the deputy, and next week hongbin will be.
14:15:59 <slaweq> sounds good for me
14:16:05 <lajoskatona> slaweq: thanks
14:16:31 <lajoskatona> #topic On Demand Agenda
14:16:56 <lajoskatona> We have a few topics
14:17:02 <lajoskatona> lajoskatona: #link https://bugs.launchpad.net/neutron/+bug/1942329 MAC address of direct-physical port is not updated during migration
14:17:23 <lajoskatona> actually gibi has this nice bug
14:17:24 <gibi> o/
14:17:29 <gibi> I can summarize
14:17:36 <gibi> so for most of the neutron port
14:17:36 <gibi> s
14:17:41 <lajoskatona> gibi: thanks
14:17:48 <gibi> the mac address of the port is set on the device in the backend
14:17:53 <gibi> but for direct-physical ports
14:17:56 <gibi> it is in revers
14:18:04 <gibi> nova sets the mac of the neutron port based on the backend device
14:18:28 <gibi> however that mac is not updated when the VM is moved to another host
14:18:45 <gibi> there are two reasons why
14:18:51 <gibi> 1) nova does not even try to update
14:19:14 <gibi> 2) if nova try the update would fail as neutron does not allow updating a mac on a bound port
14:19:46 <gibi> after a bit of deliberation I think the nicest way to fix this is to let nova record the PF mac in the binding profile
14:20:13 <gibi> and change neutron to overwrite the port.mac_address based on the active port binding (if any) for direct-physical ports
14:20:34 <gibi> the question is, do you accept such change
14:21:02 <gibi> I've just pushed a WIP patch https://review.opendev.org/q/topic:bug/1942329
14:21:14 <ralonsoh> but I don't understand: this port should have the correct MAC, set in the first bind
14:21:47 <gibi> the direct-physical port will have the correct MAC at first bind yes. Nova sets it _before_ requesting the binding
14:22:11 <gibi> but when the VM moves to another host it gets another PF with a different MAC
14:22:45 <gibi> and that new MAC is not reflected today in the neturon port.mac_address field
14:22:59 <gibi> that field still points to the PF on the previous host
14:23:09 <ralonsoh> ahhh, Nova doesn't change the destination mac
14:23:09 <gibi> making that PF unusable for another port
14:23:17 <ralonsoh> could it be a problem?
14:23:17 <gibi> ralonsoh: yes
14:23:27 <gibi> yes and yes :)
14:23:33 <ralonsoh> that the VM starts with another MAC?
14:23:53 <ralonsoh> in any case, I'll review the patch offline
14:23:54 <gibi> I guess the dhcp agent expects the mac in the port
14:24:00 <gibi> so that is a problem
14:24:03 <lajoskatona> if I understand well nova orlibvirt just reads and reuse the mac of the pf
14:24:13 <ralonsoh> yes
14:24:14 <gibi> lajoskatona: yes,
14:24:19 <gibi> ralonsoh: thanks
14:24:31 <gibi> I'm fine moving this discussion to the review
14:24:42 <obondarev> and for the new VM on the first host that would be a problem - MAC will be in use, right?
14:24:55 <gibi> obondarev: right, exactly
14:25:02 <mlavalle> double whammy
14:25:05 <gibi> obondarev: the source host PF become unusable due to MAC conflicty
14:25:20 <obondarev> I think we faced smth like that before
14:25:29 <gibi> obondarev: yes https://bugs.launchpad.net/neutron/+bug/1830383
14:25:41 <gibi> obondarev: this fixed some part of it
14:25:46 <gibi> obondarev: but not the migration case
14:25:52 <obondarev> gibi: yes! thanks!
14:26:02 <obondarev> gibi: ack
14:26:33 <gibi> anyhow now you now that I would like to change the binding profile and the mac_address logic for PF ports. that was my goal with this meeting topic :)
14:26:39 <gibi> s/now/know/
14:27:06 <lajoskatona> gibi: thanks
14:27:10 <gibi> lajoskatona: thanks all
14:27:36 <lajoskatona> ok, next topic:
14:27:43 <lajoskatona> (dmitriis): #link https://review.opendev.org/q/topic:bug%252F1932154 Off-path backend series & remote-managed port support
14:27:47 <fnordahl> Was hoping to ask politely for reviews of this series https://review.opendev.org/q/topic:bug/1932154+-status:abandoned  Two of the patches are currently getting -1 from Zuul awaiting the neutron-lib release, but we have demonstrated passing tests prior to the last minut change of VNIC type.  It is targeted for Yoga and the next milestone and subsequent FF is coming closer.
14:27:58 <fnordahl> The Nova side of the feature has merged
14:28:05 <fnordahl> The OVN side is merged
14:28:20 <opendevreview> Merged openstack/neutron stable/xena: [OVN] Migrate "reside-on-redirect-chassis" for distributed FIP  https://review.opendev.org/c/openstack/neutron/+/828727
14:28:26 <lajoskatona> the n-lib release is on its way, so hope that will push things
14:29:28 <lajoskatona> fnordahl: I will check these
14:29:33 <dmitriis> yeah, just trying to raise awareness since the freeze is coming. It's smaller than the Nova series but still worth allowing some time for.
14:29:38 <dmitriis> lajoskatona: tyvm
14:30:01 <fnordahl> thanks lajoskatona
14:30:20 <slaweq> so all those red CI results in those patches are due to missing neutron-lib release, right?
14:30:26 <dmitriis> slaweq: yep
14:30:27 <fnordahl> yes
14:30:28 <slaweq> e.g. in https://review.opendev.org/c/openstack/neutron/+/808961
14:30:30 <lajoskatona> fnordahl, dmitriis: we can increase review priority if we have to hurry
14:30:31 <slaweq> ok
14:31:07 <fnordahl> milestone 3 is next week as far as I understand the schedule, so there is not much time
14:31:54 <lajoskatona> yes and the wee kafter that is rc1
14:33:12 <lajoskatona> thanks for the headsup, if there's any series that we have to push please tell us
14:33:34 <dmitriis> ack. From our side, I can promise quick feedback on any comments on the changes
14:33:44 <fnordahl> indeed, and thanks alot for your help
14:33:51 <lajoskatona> +1, thanks
14:34:30 <lajoskatona> The last On demand topic is:
14:34:53 <lajoskatona> (lajoskatona): Outreachy: http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027239.html
14:35:26 <lajoskatona> this outreachy program is to mentor students and they learn and try to help openstack projects
14:36:07 <lajoskatona> this semester is just starting so if there's any which we think a student can help around Neutron, we can ask in the coming weeks
14:36:39 <mlavalle> I'd be happy to help with Neutron topics
14:36:57 <lajoskatona> I suppose the task must be clear enough like specific bug
14:37:04 <lajoskatona> mlavalle: thanks
14:37:29 <elvira> if someone thinks of a project to present and wants some help with dedicating time to the student, I'd love to help
14:37:30 <lajoskatona> or things to fix like if we have ideas what to improve with CI or such things
14:37:47 <lajoskatona> elvira: cool, thanks
14:38:00 <slaweq> or some RFE maybe as IIUC it's a bit longer thing so such person can work on it for few weeks probably
14:38:11 <elvira> I just cannot think of a low-hanging series of tasks that are appropiate for a student right now, but there might be some
14:38:44 <lajoskatona> so I take it as a yes try it, and I go and check it with Outreachy organizers to have more details :-)
14:38:49 <elvira> yes, I think it's around 2 months of daily work expected from the student, slaweq
14:40:21 <lajoskatona> https://wiki.openstack.org/wiki/Outreachy/Mentors
14:40:31 <lajoskatona> here it says 3 months, but anyway not a full cycle
14:40:55 <lajoskatona> ok, thanks for the enthusiasm, I check it than with the organizers
14:41:22 <lajoskatona> That's it from me
14:41:29 <lajoskatona> Is there anything that we can discuss?
14:42:21 <lajoskatona> #endmeeting