14:00:41 <haleyb> #startmeeting networking 14:00:41 <opendevmeet> Meeting started Tue Jun 4 14:00:41 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:41 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:41 <opendevmeet> The meeting name has been set to 'networking' 14:00:50 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh 14:00:54 <mlavalle> \o 14:00:57 <obondarev> o/ 14:00:57 <ihrachys> o/ 14:00:58 <ykarel> o/ 14:01:06 <frickler> \o 14:01:11 <rubasov> o/ 14:01:12 <bcafarel> o/ 14:01:42 <slaweq> o/ 14:01:50 <haleyb> good crowd let's get started 14:01:54 <haleyb> #topic announcements 14:02:06 <haleyb> We are now in Dalmatian release week (R - 17) 14:02:12 <haleyb> #link https://releases.openstack.org/dalmatian/schedule.html 14:02:35 <lajoskatona> o/ 14:03:26 <haleyb> so if there any features that haven't been proposed please get them out soon as we are more than halfway through cycle 14:04:03 <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:04:58 <haleyb> i might take this Friday off since there are no current topics afaik, will send an email thursday if canceled 14:05:45 <haleyb> lajoskatona: how was Openinfra Day Budapest yesterday? 14:06:04 <lajoskatona> it was quiet 14:06:10 <haleyb> :( 14:06:14 <lajoskatona> a lot of AI topics 14:06:49 <lajoskatona> an digital souverignity (sorryI can't write it ....) 14:07:06 <lajoskatona> Sovereignty 14:07:39 <lajoskatona> those were in the middle of all discussions and presentations 14:07:39 <haleyb> AI does consume all the oxygen in the room compared to cloud and kubernetes these days 14:07:41 <bcafarel> that looks in line with Paris day (and same from Berlin from what I heard) 14:08:14 <lajoskatona> last week on another conf in Budapest in 2 hours there was a 14:08:25 <lajoskatona> presentation which said that AI regenerate legacy code 14:08:54 <lajoskatona> and another that stated that we are dynosaurs and we (developers) will just become extinct :-) 14:09:00 <haleyb> and it fixed all the bugs while doing it? 14:09:14 <lajoskatona> (it later changed that we have to use AI well and it will help us a lot) 14:09:50 <slaweq> yeap 14:09:56 <lajoskatona> you mean the bugs it created alone with artifical intellingence? I am abel to create bugs with m human intelligence 14:10:06 <haleyb> we all are :) 14:10:40 <mlavalle> I'm very good at that 14:10:52 <ihrachys> AI is just a compute and network hungry workload *shrugs* 14:12:01 <haleyb> that it is... 14:12:19 <haleyb> alright, we can bash AI all day, any other announcements? 14:12:54 <haleyb> #topic bugs 14:13:19 <mlavalle> thnaks for the update lajoskatona :-) 14:13:44 <haleyb> lucas was the deputy last week, but i didn't see a report on the ML 14:14:51 <haleyb> did anyone have any bugs to talk about? i will look quickly in the meanwhile 14:15:43 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2067515 14:15:44 <haleyb> neutron-lib: add a job running neutron unit test suite (maybe non-voting) 14:16:02 <haleyb> this was something ihrachys noticed when a neutron-lib change broke the neutron gate 14:16:30 <haleyb> although neutron-lib has this same job, it runs only neutron-lib unit tests 14:16:37 <ihrachys> we disabled votes for the job now, so it's not as pressing. still good to have an early warning. 14:17:29 <haleyb> right, but the next step is - is it possible to run the neutron unit tests in the neutron-lib gate? which would have detected the issue 14:17:39 <haleyb> i'm not sure that's possible 14:18:18 <haleyb> ihrachys: i actually wanted to talk about making that job non-voting today but realized i never pushed my comment to the patch 14:18:34 <ihrachys> I'm sure it's possible! perhaps not as easy? I dunno. ykarel is it possible / easy? 14:18:43 <haleyb> the only thing i worry about non-voting is that noone notices when there's a real bug there 14:19:02 <ykarel> ihrachys, haleyb i think should be possible and not that hard 14:19:10 <ykarel> consider similar jobs run in requirements patches 14:19:12 <haleyb> and having the latest sqlalchemy running correctly is a good thing 14:19:19 <ihrachys> haleyb let ci folks track if this job starts crashing? they do periodic group watching at charts I think. 14:19:27 <ykarel> a run https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_b27/920454/1/check/cross-neutron-py311/b27fe41/testr_results.html 14:19:44 <haleyb> ihrachys: true, we are much better now at noticing 14:20:17 <ihrachys> (and ideally, we have a non-voting job in neutron-lib and don't even merge anything without first checking how it fares) 14:20:30 <ykarel> +! 14:21:04 <haleyb> ihrachys: yes, that would be ideal, then we could make the neutron job voting again since it shouldn't break 14:21:21 <ihrachys> ykarel I'll be impolite and ask - is it something ci group will take care of? 14:21:43 <ihrachys> :) 14:21:56 <ykarel> haleyb, it can still break as sqlalchemy patches are not gated 14:22:01 <ykarel> so we can keep it still non-voting 14:22:20 <ykarel> ihrachys, yes sure, i think you already have a bug for that so can be tracked there 14:22:21 <haleyb> ykarel: sure, understood 14:22:33 <ihrachys> ykarel ++ I don't think it's a good idea to keep it voting. it's exposed to the world, not isolated with constraints. 14:22:53 <ykarel> +1 agree 14:23:49 <haleyb> ykarel: can you take that bug and propose a neutron-lib patch? 14:24:12 <ykarel> ack will do 14:24:24 <ihrachys> ykarel thank you. 14:25:06 <haleyb> ykarel: thanks! 14:26:18 <haleyb> i only noticed one other bug 14:26:29 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2067871 14:26:30 <haleyb> No support on using domain name for ovn connection string in ml2_conf.ini 14:27:02 <ihrachys> thought there was a fix in python-ovs from otherwiseguy for this 14:27:09 <haleyb> since the help message states tcp:IP:PORT is the format, using a dns name is more of a enhancement 14:27:18 <haleyb> ihrachys: oh, i don't know 14:27:28 <ihrachys> I think this https://github.com/openvswitch/ovs/commit/4d55a364ff60d894dce4e2e97a489d81520dc663 14:27:29 <ykarel> i recall it's in ovs3.1 14:27:51 <ykarel> ok so 3.2 as per above commit :) 14:28:58 <haleyb> it's unclear from that commit message it relates to this imho 14:29:39 <ihrachys> unless it was backported. anyhoo, pretty recent. we needed it to point clients to a round-robin backed by k8s dns. 14:29:40 <ykarel> apart from the ovs3.1 python3-unbound is required for that to work 14:29:44 <haleyb> but the link to the ML is clearer 14:29:45 <ykarel> s/ovs3.1/ovs3.2 14:29:55 <ihrachys> haleyb and yet it is related, 99% sure :) 14:30:27 <ihrachys> this was a discrepancy between python-ovs and C behavior (the latter was resolving before) 14:31:18 <haleyb> ihrachys: ack, so it seems if we bump the requirement, change the help text and add a test we should be good 14:32:20 <haleyb> i can add that info to the bug 14:32:21 <ihrachys> meh. I don't think we promised anywhere it will work?.. 14:32:38 <ihrachys> we can definitely mention somewhere that DNS may work, depending on your OVS version. 14:33:03 <haleyb> oh, this is in ovs not ovsdbapp 14:33:06 <haleyb> doh 14:33:52 <ihrachys> yep 14:34:58 <lajoskatona> Perhaps 2 bugs for os-ken: https://bugs.launchpad.net/neutron/+bug/2067970 & https://bugs.launchpad.net/neutron/+bug/2067973 14:35:44 <lajoskatona> both marked as vulnerability and as I see both come from a non-Neutron usecase which we don't test in Openstack CI most probably 14:35:45 <haleyb> that second one is private so maybe not visible 14:35:58 <ihrachys> both are 404 for me 14:36:13 <ihrachys> so probably not a good idea to discuss it here :) 14:36:16 <lajoskatona> ahh, ok 14:37:02 <lajoskatona> just a general thing to think about then: if it is not Openstack usecase how to handle this? do we want to take responsibility to the code part of os-ken that is not used by Openstack 14:37:08 <lajoskatona> just inherited from ryu? 14:37:58 <ihrachys> (not idea what we are talking about but) if it's not used, just yank it. 14:38:24 <ihrachys> that we carry dead code is a problem in itself imo 14:39:13 <lajoskatona> It can be a topic of some of the coming meetings, driver or later the PTG perhaps to collect all these 14:39:37 <haleyb> lajoskatona: maybe propose that in the bug 14:40:00 <haleyb> to remove the unused (broken) code 14:40:17 <lajoskatona> haleyb: ack, I check them and add comment to them 14:40:31 <haleyb> +1 14:41:03 <haleyb> and just an update on the cover job bug 14:41:04 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2065821 14:41:22 <haleyb> we landed a workaround that helps, using --concurrency 4 14:41:51 <haleyb> i've tried different versions of the coverage tool and memory consumption seems similar 14:42:15 <haleyb> so i guess we've always been on the edge of failure 14:42:41 <haleyb> i'm still running tests and will update the bug and ML with more info 14:43:02 <haleyb> the side-effect was learning about sql 'selectin' queries 14:43:17 <haleyb> i filed a bug for that and have two patches in-flight 14:43:34 <haleyb> #link https://launchpad.net/bugs/2067770 14:43:50 <ihrachys> I saw them bloody red. is it an intrinsic problem with the switch or just some oversights when pushing? is there a lot more work there? 14:44:12 <haleyb> ihrachys: the neutron-lib patch needs to land first, https://review.opendev.org/c/openstack/neutron-lib/+/920936 14:44:23 <haleyb> with that applied locally things are fine 14:44:34 <ihrachys> ah. we need that non-voting job to run neutron tests :) 14:44:47 <haleyb> env TOX_ENV_SRC_MODULES=../neutron-lib tox -e py3 -- neutron.tests.unit.db 14:45:01 <haleyb> ^^ that will use a local neutron-lib change 14:45:06 <ihrachys> is there a way to run full neutron check pipeline against a neutron-lib patch? 14:45:22 <ykarel> depends-on will do that 14:45:38 <haleyb> ihrachys: no since it's a library, unless something has changed 14:45:43 <ihrachys> ykarel doesn't it still use neutron-lib released version? 14:46:09 <ykarel> it should use neutron-lib from git atleast in devstack jobs 14:46:24 <slaweq> we have in experimental/periodic queue job which uses neutron-lib from master 14:46:24 <ykarel> for orther too it should work but can cross check 14:46:36 <slaweq> for that job depends-on should works 14:46:36 <ihrachys> that's news to me. you are saying it pulls master neutron-lib in devstack? 14:46:54 <ykarel> yeap if there is depends-on 14:46:54 <haleyb> and the sqlalchemy job does too, but the patch has to have landed 14:47:44 <ihrachys> I mean, SOME jobs like that sqlalchemy definitely check out from git and for them depends-on will work. for the rest - I dunno, I had different perception but I'd rely on ykarel who knows 100x more than me. 14:47:48 <slaweq> ykarel that's also new for me - IIRC in the past depends on wasn't working as neutron-lib was always installed from package 14:47:55 <ykarel> https://github.com/openstack/devstack/blob/92d70a854322be9cb22f574618d7663be9a4e649/lib/neutron#L531 14:48:19 <ykarel> so need to check if there is required-projects contain neutron-lib, if it does then only will work 14:48:34 <haleyb> ykarel: right, but that assumes the neutron-lib patch has merged, correct? 14:49:14 <ihrachys> not necessarily. I think depends-on will prepare git clones in the env to include the patch depended-upon. then devstack will checkout from these "cooked" repos. 14:49:17 <ykarel> depends-on with unmerged patches should also test that 14:49:53 <ihrachys> ok. I guess we can post a depends-on DNM patch and confirm in logs, should be easier than continuing arguing :p 14:49:58 <ykarel> but the requirement is it should be in required-projects list, now thinking more i don't think we have that as we want to test with u-c 14:50:27 <ykarel> so what slaweq said if experimental jobs have that set, those could be used for such tests 14:50:37 <haleyb> ykarel: so i should be able to add a depends-on to my neutron patch? you can explain later 14:50:46 <ykarel> +1 14:50:46 <ihrachys> right. well, having SOME jobs tested against the patch is better than nothing. 14:51:09 <ykarel> yes for test atleast we can hack it 14:51:21 <haleyb> but please take a look at the patches, i think the neutron-lib is easy enough - https://review.opendev.org/q/topic:%22orm-selectin%22 14:52:02 <lajoskatona> +1, thanks 14:52:25 <ihrachys> that's one of those cases where a single line change affects every single code path. reviewing the diff is 1% of validation. 14:52:27 <haleyb> jlibosva is deputy this week, can someone at RH ping him since i don't see him in channel 14:52:52 <ihrachys> he's busy with an escalation but I will ping, sec. 14:53:10 <haleyb> sure, just so he knows 14:53:35 <haleyb> anyone have other bugs to discuss? 14:54:20 <haleyb> #topic on-demand 14:54:27 <haleyb> open floor for any other topics 14:55:16 <ihrachys> I want this in https://review.opendev.org/c/openstack/neutron-lib/+/917855 and then cut neutron-lib that is netaddr1 compliant 14:55:26 <ihrachys> (this is the last bit for this) 14:55:49 <frickler> regarding the n-d-r spec you discussed on friday, I would prefer to just maintain n-d-r in the state it currently is, no new features added 14:55:59 <haleyb> ihrachys: will take a look 14:56:06 <frickler> at least I don't have review capacity for anything more 14:56:54 <haleyb> frickler: was that https://bugs.launchpad.net/neutron/+bug/2064120 ? 14:57:25 <frickler> yes 14:57:34 <ihrachys> frickler there's another spec related to bgp where I was pushing for reusing the API for n-d-r. Wonder if this project is on life support, what Neutron project as a whole should do with it. APIs are still part of api-ref, so neutron as a whole care. 14:58:15 <frickler> ihrachys: which spec are you referring to? 14:58:18 <ihrachys> https://review.opendev.org/c/openstack/neutron-specs/+/920681 14:59:05 <frickler> also I don't mind if other neutron cores review n-d-r patches, it is just that I myself mostly won't other than real bug fixes 14:59:15 <ihrachys> but may mix n-d-r and bgpvpn; I'm a bit shaky on who's who. 14:59:53 <haleyb> and ovn-agent 15:00:01 <frickler> ah, hadn't seens that one yet, will take a look later 15:00:05 <haleyb> or whatever it's called :) 15:00:19 <ihrachys> haleyb those pesky ovn engineers. 15:00:42 <haleyb> we are at top of hour, thanks for attending and good discussions, let's go fix those bugs 15:00:54 <haleyb> and ci meeting is irc right now 15:01:10 <haleyb> #endmeeting