14:00:43 <haleyb> #startmeeting networking
14:00:43 <opendevmeet> Meeting started Tue Jan 21 14:00:43 2025 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:43 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:43 <opendevmeet> The meeting name has been set to 'networking'
14:00:54 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh
14:00:55 <mlavalle> \o
14:01:00 <ralonsoh> hello
14:01:00 <svinota> ralonsoh, I couldn't login to edit the wiki page, so if there will be one-two minute for an ad-hoc announce in the end of the meeting, would be nice.
14:01:20 <ralonsoh> ralonsoh, sure, there will be time
14:01:22 <slaweq> o/
14:01:38 <rubasov> o/
14:01:58 <lajoskatona> o/
14:01:59 <haleyb> svinota: there will be an on-demand time at the end, thanks for attending
14:02:06 <svinota> thanks
14:02:13 <haleyb> #announcements
14:02:35 <haleyb> We are in week R-10 if my math is correct
14:02:41 <haleyb> #link https://releases.openstack.org/epoxy/schedule.html
14:03:15 <opendevreview> Rodolfo Alonso proposed openstack/neutron master: WIP == [eventlet-deprecation] Remove the usage of eventlet in the Neutron API  https://review.opendev.org/c/openstack/neutron/+/938659
14:03:20 <haleyb> in R-6 we will have non-client library freeze
14:03:32 <opendevreview> Rodolfo Alonso proposed openstack/neutron master: DNM - Test "neutron-ovn-tempest-ipv6-only-ovs*" with WSGI  https://review.opendev.org/c/openstack/neutron/+/932601
14:03:33 <haleyb> in R-5 will be E-3 milestone
14:03:38 <bcafarel> late o/
14:05:07 <haleyb> Reminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
14:05:18 <haleyb> And of course a reminder to use the priorities dashboard for patches in the "ready to merge" state
14:06:05 <haleyb> I sent the Linuxbridge removal email to the ML last week, and it seems people have accepted is was the right thing to do
14:07:01 <slaweq> great :) thx haleyb for doing this finally
14:07:02 <haleyb> there was a related email from Cern regarding knowledge sharing
14:07:06 <lajoskatona> good question if heores will move the code to x/ namsspace, let's see:-)
14:08:52 <haleyb> i will not hold my breath on that, i would hope we can spend any time helping with migration questions and OVN adoption
14:09:12 <lajoskatona> +1 for pushing toward migration
14:09:47 <haleyb> i did not have any other announcements
14:10:16 <haleyb> #topic Bugs
14:10:21 <haleyb> lajoskatona was deputy last week
14:10:26 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/JIRUHN7HMJUDB7KB55UYUZ5Q2IK2MC6X/
14:10:36 <haleyb> there were quite a few
14:11:19 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: async_process: fix potential race condition with respawn  https://review.opendev.org/c/openstack/neutron/+/939627
14:11:20 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: async_process: remove usage of eventlet for AsyncProcess  https://review.opendev.org/c/openstack/neutron/+/939348
14:11:20 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: ovs: reimplement signals handling  https://review.opendev.org/c/openstack/neutron/+/939321
14:11:21 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: common: fix wait_until_true to support native thread  https://review.opendev.org/c/openstack/neutron/+/937843
14:11:21 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: ovs: remove the usage of eventlet in the OVS agent  https://review.opendev.org/c/openstack/neutron/+/937765
14:11:33 <haleyb> lajoskatona: were there any bugs you wanted to highlight?
14:12:31 <lajoskatona> not really there were few without owners
14:12:55 <lajoskatona> but as I remember the high prio ones are under control
14:13:15 <haleyb> ok
14:13:18 <lajoskatona> https://bugs.launchpad.net/neutron/+bug/2094842
14:13:27 <lajoskatona> this one in the high list without owner
14:13:37 <lajoskatona> "ovs.db.error.Error: ovsdb error: 0 values when type requires between 1 and 9223372036854775807" when router is attached to network without subnet
14:13:40 <haleyb> that looks familiar, or at least we just fixed something related in quota
14:14:10 <haleyb> at least it looks like the quota one, but it wasn't in ovsdb of course
14:14:40 <ralonsoh> the cause is explained in the description
14:14:41 <haleyb> oh, maybe this is related to a fix ralonsoh had regarding gw_port without an IP address?
14:14:51 <ralonsoh> we can't create a GW port wihtout subnet in the GW network
14:15:13 <ralonsoh> haleyb, I don't have anything yet
14:15:25 <ralonsoh> there is a quick attempt https://review.opendev.org/c/openstack/neutron/+/939253
14:15:32 <ralonsoh> but this is something that needs to be tested
14:16:12 <haleyb> ralonsoh: ah, that was it, it was ihrachys not you, sorry i mis-remembered
14:17:03 <lajoskatona> it is visible in zuul logs also not just for master
14:17:13 <lajoskatona> see the opensearch logs I added as comment
14:18:16 <haleyb> ack, i guess we can wait until that change is updated to see if it fixes it
14:18:33 <lajoskatona> +1
14:18:56 <haleyb> another one ihar filed was
14:19:02 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2094846
14:19:22 <haleyb> trunk driver functional failure
14:20:26 <haleyb> according to codesearch there was only 1 failure so far, but it looks like something that shouldn't have happened
14:20:32 <ralonsoh> it happened only once
14:20:40 <ralonsoh> and this is a functional test
14:20:53 <ralonsoh> I would reduce the importance, but I'll keep it in the list
14:21:17 <haleyb> yes, let's see if it happens again first
14:21:21 <lajoskatona> it is medium at the moment due to low frequesncy, but we can dereease
14:22:19 <haleyb> sure
14:22:38 <haleyb> there was another medium i started to take a look at
14:22:42 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2095097
14:22:49 <haleyb> 500 error creating resource with emoji for name
14:23:11 <haleyb> it happens for any string field, for example, description too
14:23:28 <lajoskatona> that's a funny one, but really happens
14:23:50 <haleyb> my original thought was to just fix the network db code, but now i think we should change neutron-lib to add a validator for such fields
14:23:59 <haleyb> but i wanted to get others thoughts on that
14:24:16 <ralonsoh> an extra check for printable chars is ok
14:24:23 <lajoskatona> haleyb: yes a validator sounds good
14:24:30 <ralonsoh> it won't break anything using "normal" chars
14:24:50 <ralonsoh> and with the n-lib validator, we'll have a printable exception, not error 500
14:24:50 <haleyb> and i'm not sure it's a medium as i originally tagged it, since it only affects the caller
14:25:21 <ralonsoh> the only problem here is to return a valid exception
14:25:22 <haleyb> yes, a quick hack of the network db code and i could get a 400,
14:25:23 <ralonsoh> not 500
14:25:33 <ralonsoh> so I would lower the priority
14:25:37 <haleyb> i.e. InvalidInput such exception
14:25:43 <ralonsoh> exactly
14:26:26 <lajoskatona> nova gives back 400 for such input for example
14:26:54 <ralonsoh> as it should be, this is a bad request, not a server error
14:27:19 <lajoskatona> exactly, so good to have simlar response from Neutron API also
14:27:53 <slaweq> ++ for some 4xx error in such case
14:28:23 <haleyb> i took it and can work on a validator
14:28:40 <haleyb> next unowned bug
14:28:45 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2095185
14:29:03 <haleyb> ihrachys was busy last week
14:29:33 <haleyb> test_legacy_router_conntrack_helper failure
14:29:35 <lajoskatona> even on Friday I got a bunch of bugs from Him :-)
14:29:51 <haleyb> he gave a possible solution, but would need more investigation
14:29:58 <lajoskatona> this one was seen in zuul logs only on stable/
14:30:07 <ralonsoh> last sentence of the description is a clue for a fix
14:30:19 <ralonsoh> so I would give a try
14:30:26 <lajoskatona> but as he wrote can happen on master
14:30:34 <opendevreview> Ihar Hrachyshka proposed openstack/neutron master: QinQ implementation for the ML2/OVN backend  https://review.opendev.org/c/openstack/neutron/+/937633
14:30:51 <haleyb> right, just needs an owner if someone can take it
14:31:38 <haleyb> the last bug without owner is
14:31:44 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2095091
14:32:28 <haleyb> ykarel_: you filed this, does it happen frequently enough to debug it further?
14:32:39 <lajoskatona> yesterday we discussed on the CI meeting with ykarel and slwaq and mlavalle
14:32:49 <ykarel_> haleyb, happened only once
14:32:50 <haleyb> ah
14:33:02 <ykarel_> mlavalle, will be working on alternative
14:33:02 * haleyb was out yesterday as it was a holiday
14:33:32 <haleyb> ok, as long as someone is working on it
14:33:45 <haleyb> any other bugs to discuss?
14:34:19 <haleyb> ykarel is the deputy this week, mtomaska next week
14:34:26 <haleyb> is that ok?
14:35:33 <haleyb> i will follow-up later so we can move along with other items
14:35:37 <haleyb> #topic community goals
14:36:04 <mlavalle> haleyb ykarel I'll keep an eye on that failure
14:36:09 <haleyb> ack
14:36:22 <haleyb> lajoskatona: seems forward progress on neutronclient deprecation?
14:36:28 <haleyb> #link https://review.opendev.org/q/topic:%22bug/1999774%22
14:36:43 <ykarel> haleyb, ack for deputy, thx for the reminder
14:36:44 <lajoskatona> not this week, I had no time for it
14:37:16 <haleyb> well, at least both open changes have zuul +1, i will take a look at the second in the chain
14:37:26 <lajoskatona> thanks
14:38:22 <haleyb> and evenlet deprecation
14:38:35 <ralonsoh> this is not going well
14:38:47 <ralonsoh> I can't identify what is happening
14:38:59 <ralonsoh> initially the hash ring manager was a possible culprit
14:39:22 <ralonsoh> but since last week (we merged a patch), the timeouts are increased and we don't have idle nodes
14:39:49 <ralonsoh> now the problem is, sometimes, that the events are processed in different order, DB locks and other problems I can't explain
14:40:02 <ralonsoh> I'm trying to open the related bugs
14:40:09 <ralonsoh> and I'm trying with this:
14:40:16 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/938659
14:40:42 <ralonsoh> there are many places in the code (python-ovs, ovsdbapp, Neutron, etc) where the libraries have workarounds for eventlet
14:40:44 <ralonsoh> so I'
14:40:46 <ralonsoh> sorry
14:41:01 <ralonsoh> so I would prefer testing Neutron API without eventlet
14:41:07 <opendevreview> Merged x/whitebox-neutron-tempest-plugin master: Add config dict dataplane_podified_services  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/939519
14:41:10 <ralonsoh> because this is actually the expected behaviour
14:41:29 <ralonsoh> and that's all (I'm overwhelmed right now)
14:43:20 <haleyb> ralonsoh: what else can we do to help? i know ihrachys was helping last week, and i can look at things this week
14:43:36 <haleyb> but i realize it is very complicated
14:43:47 <ralonsoh> haleyb, first of all, trying to check what is happening in CI patches like https://review.opendev.org/c/openstack/neutron/+/932601/12?tab=change-view-tab-header-zuul-results-summary
14:44:17 <ralonsoh> even without eventlet, I see common errors (ports not active, PG not present, etc)
14:44:53 <ralonsoh> so, for example, to take one CI log and try to squeeze it to find what was the problem
14:45:30 <haleyb> ack, and i would ask anyone with spare cycles to take a look so we come up with some ideas
14:46:17 <lajoskatona> I ry to allocate some time to it, anyway the n-d-r issue is also there with the same root
14:46:24 <haleyb> thanks
14:46:41 <haleyb> i want to move to on-demand as svinota is here
14:46:44 <haleyb> #topic on-demand
14:46:52 <ralonsoh> svinota, hello!
14:46:56 <svinota> hello
14:47:06 <svinota> and thanks for your time :)
14:47:17 <haleyb> thanks for pyroute2 :)
14:47:26 <lajoskatona> Welcome :-)
14:47:38 <svinota> so shortly, the pyroute2 project is undergoing a big (to say the least) shift in the core
14:48:07 <svinota> I continue to support the old synchronous API, it will not be dropped
14:48:28 <svinota> but from 0.9.1 the core is based on asyncio
14:48:49 <svinota> related docs: https://docs.pyroute2.org/asyncio.html
14:48:58 <svinota> also: https://docs.pyroute2.org/iproute_intro.html
14:49:15 <svinota> thanks to ykarel , I start to monitor the zuul as well
14:50:02 <svinota> so I hope not to miss major compatibility errors; beside of that I run own integration tests
14:51:15 <svinota> I don't know how this shift can affect the neutron core, so as I said — I keep the sync API anyways
14:51:54 <svinota> but if the project can provide something more within the async paradigm — let me know
14:52:01 <haleyb> is there a point in time where we should start migrating things? will there be gotcha's, etc?
14:52:05 <svinota> that's all folks :) thanks
14:52:12 <ralonsoh> this is a bug change, of course. We use pyroute "only" in the agents (luckily, because asyncio is not compatible with wsgi)
14:52:35 <ralonsoh> and most of the pyrouter calls are executed inside a root daemon (privsep)
14:52:59 <ralonsoh> so we'll need to refactor the non-admin calls and the admin calls independetly
14:53:08 <ralonsoh> can both coexist right now?
14:53:29 <svinota> 0.9.1 is scheduled for the beginning of February, but as I see, the current neutron code works with the master branch
14:53:42 <svinota> and the master branch is already async-enabled
14:53:46 <ralonsoh> perfect
14:53:53 <svinota> so I believe no migration is required
14:54:07 <ralonsoh> but eventually this is the desired implementation, right?
14:55:05 <svinota> async is the first class citizen now, so the sync code is simply a set of wrappers around it; so you can use either variant, totally up to you, both will coexist
14:55:24 <ralonsoh> perfect
14:55:32 <svinota> in the best case the library users should not notice any change
14:55:59 <slaweq> svinota thx for sharing all of that with us
14:56:05 <svinota> (it took like some months to fix it in that way, but I hope it pays back)
14:56:14 <slaweq> but neutron is not the only user of the pyroute2 in openstack
14:56:25 <ralonsoh> os-vif, right
14:56:27 <slaweq> did you maybe had any chance to test it with other projects as well?
14:56:34 <ralonsoh> and other projects in networking
14:56:38 <slaweq> octavia I see is using it a bit
14:57:06 <svinota> I tested kuryr. Octavia should work as before.
14:57:08 <ralonsoh> so this should be on us to create pyroute-master CI jobs
14:57:11 <slaweq> https://codesearch.opendev.org/?q=pyroute2&i=nope&literal=nope&files=&excludeFiles=&repos=
14:57:16 <slaweq> I see many of them really
14:57:16 <svinota> I forgot os-vif, thanks
14:57:33 <slaweq> I don't want you to test them all on your own
14:57:58 <haleyb> ralonsoh: we do have functional and fullstack pyroute2 master jobs
14:58:05 <svinota> slaweq, thanks for the link. I will try to go through the list and see if we can include them in the integration testing
14:58:07 <slaweq> but maybe you could send email to the openstack-discuss ML to raise awarness of this change in different teams
14:58:14 <ralonsoh> haleyb, yes but for all projects?
14:58:43 <haleyb> ralonsoh: i only know of neutron
14:58:50 <lajoskatona> perhaps some common tempest integration job?
14:58:59 <lajoskatona> that an cover a lot of projects
14:59:25 <slaweq> svinota thx a lot, if you will have any questions about it, please ping me :)
14:59:36 <svinota> slaweq, 10x
15:00:01 <ralonsoh> ok, let's create a bug in LP to handle this
15:00:11 <ralonsoh> to create the needed CI jobs for pyroute-master
15:00:16 <ralonsoh> functional or tempest
15:00:37 <ralonsoh> and, of course, svinota thanks a lot
15:00:55 <lajoskatona> and advertise it on mail list to have a flag for all users not just for us
15:01:09 <svinota> thanks, colleagues
15:01:22 <lajoskatona> svinota thanks for the good cooperation and for the news :-)
15:01:38 <haleyb> yes, thanks a lot svinota!
15:02:01 <haleyb> does anyone want to file the bug, etc? or is this on the PTL :)
15:02:32 <lajoskatona> always the one who asks :-)
15:02:43 <slaweq> haha
15:02:58 <haleyb> ok, i have to drop for another meeting
15:03:07 <haleyb> thanks everyone for attending, have a good week
15:03:12 <slaweq> o/
15:03:14 <haleyb> #endmeeting