14:00:08 #startmeeting networking 14:00:08 Meeting started Tue Oct 5 14:00:08 2021 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:08 The meeting name has been set to 'networking' 14:00:11 o/ 14:00:13 o/ 14:00:43 hi 14:00:46 hi 14:00:47 hi 14:01:25 Ok, I think we can start 14:01:29 #topic Announcements 14:01:48 Xena cycle calendar: https://releases.openstack.org/xena/schedule.html 14:01:57 This week is Xena release week: http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025158.html :-) 14:01:59 o/ 14:02:05 so we are older one cycle again :-) 14:02:22 o/ 14:02:26 We are getting close to the end of the alphabet 14:02:56 o/ 14:02:59 I think we finally have every patch merged to xena, thanks everybody for that 14:03:10 bcafarel: true 14:03:30 congrats everyone :) 14:03:48 bcafarel: don't remember if there was any plan for that already how to continue, start from "a" again? 14:04:01 so we are in Yoga now? 14:04:42 mlavalle: officially this week is R-0 of xena 14:04:47 so not yet 14:05:01 lajoskatona: I guess it will loop yes 14:05:09 but for practical purposes, like reviewing and merging, we are, aren't we? 14:05:24 but technically master branch is already for Yoga since couple of weeks 14:05:31 I think so, stable/xena branches exist everywhere now (and RC2 is out) 14:05:37 yeah, that's what I meant 14:05:38 mlavalle: yes, as xena is cut, and master can go forward 14:06:28 ok, I have 2 small highlights: 14:06:40 Alex Kavanagh proposed openstack/neutron stable/wallaby: Move dns-integration extension to the ML2_SUPPORTED_API_EXTENSIONS list https://review.opendev.org/c/openstack/neutron/+/812509 14:06:41 Openinfra episode this Thursday: OpenInfra Live Ep. 25: OpenStack Xena- Open Source Integration and Hardware Diversity 14:06:49 https://www.youtube.com/watch?v=aqilhEmkEBw&ab_channel=OpenInfrastructureFoundation 14:07:23 Neutron has few minutes to talk about cyborg integration together with Nova and Cyborg 14:07:56 and ot tell about technical debt reduction in Neutron (and other projects will be on stag as well) 14:08:08 slides for it (please check Cyborg integration and technical debt reduction) 14:08:25 please check if you have few minutes and tell me what I missed what to include 14:08:55 Next Thursday the openinfra episode will be around Neutron scaling: https://www.youtube.com/watch?v=4ZLqILbLIpQ&ab_channel=OpenInfrastructureFoundation 14:09:40 That will be mostly the production of slaweq :-) 14:09:52 lajoskatona: really? :) 14:09:57 but if you have scaling stories, that would be helpful 14:10:01 I though we will be together there ;) 14:10:17 slaweq: Yeah, but ttx asked you first :P 14:10:28 :D 14:10:31 ok 14:10:43 and You all are more than welcome there 14:11:01 You can help answering questions e.g. on chat etc. 14:11:42 yeah, the live chat will be open 14:12:24 Ok, is there anything more to announce or for announcements? 14:12:34 not from me 14:12:40 me neighter 14:12:48 slaweq: Removing the UT (but not the rest of the patch which is a one-liner) fixes it in Stretch (and I guess in Buster too, will build right away now ...). 14:12:55 ok next topic 14:13:00 #topic Bugs 14:13:02 zigo++ 14:13:12 Oh, sorry. 14:13:26 rubasov was bug deputy last week: http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025177.html 14:13:58 I found 2 unassigned bugs from the report: 14:14:01 https://bugs.launchpad.net/neutron/+bug/1945283 test_overlapping_sec_grp_rules from neutron_tempest_plugin.scenario is failing intermittently 14:14:10 https://bugs.launchpad.net/neutron/+bug/1945306 [dvr+l3ha] north-south traffic not working when VM and main router are not on the same host 14:14:21 rubasov: anything to add to the report? 14:14:44 the dvr+l3ha kombo may be broken for some time, if we analyzed it correctly 14:15:09 the reporter indentified the bugfix that introduced the regression 14:15:37 so I hope dvr experts have some ground to start from 14:16:19 regarding the 'still being triaged' metering bug 14:16:36 this would be good if liuyulong could take a look 14:16:56 it turned out it wasn't really in an ovn environment (was a typo between ovs and ovn) 14:17:15 I think this week liuyulong is still on PTO, but not sure 14:17:46 however as I looked into our docs, they are quite ambiguous about if ovn supports metering or not, so that could be fixed in the support matrix regardless 14:18:38 this is the metering bug just for the log: https://bugs.launchpad.net/neutron/+bug/1945560 14:18:44 lajoskatona: thanks 14:19:42 that bug report is probably more like a support request now (knowing it's about ovs env) 14:20:26 thanks rubasov for the report and for the triaging 14:20:32 of course 14:20:51 This week ralonsoh is the deputy, and next week lucasgomes will be, is that ok? 14:20:59 ok 14:21:25 cool, we are in good hands 14:21:46 ok I will contact lucasgomes to be sure :-) 14:21:54 mlavalle: true :-) 14:21:58 ralonsoh: estuve tentando a decir que estamos jodidos 14:22:03 hehehehe 14:22:09 (don't translate that) 14:22:16 I won't 14:23:08 LOL 14:23:21 :) 14:23:26 * slaweq had to translate that when ralonsoh said not to do this :D 14:23:37 ok, liuyulong is not here, do you have anything for L3? 14:23:58 not from me 14:24:48 ok, last topic then 14:24:51 #topic On Demand Agenda 14:25:39 There's nothing on the meeting wiki 14:26:05 I had 1 question though, which I just started to dicsuss with Heat team 14:26:24 Heat is now using neutronclient as client 14:27:10 for me it is double work to have everything in openstacksdk and in neutronclient as well, shall I hear your opinion on this? 14:27:33 Perhaps I dig into this a little more and we can discuss it during the PTG 14:27:54 neutronclient was deprecated 2 years ago, if I'm not wrong 14:27:54 what direction do you lean towards? 14:28:05 getting rid of neutronclient? 14:28:16 yeah, it has been deprecated for a long time 14:28:24 but we are still merging code 14:28:26 I think even longer than 2 years 14:28:27 ralonsoh: I guess this is about the python bindings part, which wasn't deprecated (only the cli iirc) 14:28:30 ralonsoh: yeah but we deprecated the CLI part, not the python api part, am I right? 14:28:34 IMHO it is better to implement the python bidnings in SDK and implement CLI in OSC and OSC plugin (in neutornclient repo for the stadium projects) 14:28:35 AFAIK neutronclient is actually 2 things - CLI and "lib" and that lib part isn't deprecated 14:28:43 rubasov: exactly 14:28:43 yes, the CLI, not the API 14:29:19 amotoki: correct me if I'm wrong but for now I think we have it actually like that 14:29:31 so is heat using the neutron cli? or the python bindings? 14:29:32 but to have cli in python-openstackclient we have to have binding in openstacksdk, or am I wrong? 14:29:34 of course we have also python bindings for core neutron things in neutronclient 14:29:52 lajoskatona, yes, we need SDK first 14:29:59 frickler: the python bindings 14:30:01 frickler: just the python bindings from neutronclient (I think at least) 14:31:10 on the python bindings level there should be no diff between neutronclient and sdk, am I right? 14:31:35 we have python bindings for two purposes: the one is for the core feature used by otherr projects like nova and the other is for OSC plugin for stadium projects 14:32:01 I think there are ambiguous points on the current status 14:32:03 amotoki: in neutronclient you mean? 14:32:10 lajoskatona: yes 14:32:14 in neutronclient 14:32:28 and is it possible to move all to SDK? 14:32:34 just asking 14:32:37 I think so 14:32:52 yeah, ambiguous is good word for it :-) 14:33:00 I can summarize the current status of the neutronclient repo. there are some ambigous points on the repo. 14:33:10 lajoskatona: is that what you intended when bringing up the topic? Consolidate and have one less repo to support? 14:33:23 ralonsoh: I hope yes 14:34:13 are there plans to actually drop the CLI part from neutronclient soonish? (assuming that feature-parity with OSC has been reached) 14:34:29 mlavalle: that could be the outcome, now I just realized that for new features the python bindings must be done in 2 repos, and I hate double work :-) 14:35:34 firckler: you mean to even delete the code, not just print warning if somebody use neutron net-list? 14:35:48 lajoskatona: yes 14:36:20 because the warning was there a long time when actually ignoring it was the only option 14:36:22 frickler: I think that was not discussed yet, and not sure if we have to wail after we reached the feature parity 14:36:37 so people are used to ignoring it and will continue to do so 14:36:38 frickler: that's true 14:36:42 xena neutron CLI emmits "neutron CLI is deprecated and will be removed in the Z cycle. Use openstack CLI instead." though we haven't discussed the exact cycle yet. 14:36:59 frickler: lajoskatona: actually we merged https://review.opendev.org/c/openstack/python-neutronclient/+/793366 some time ago 14:37:11 and we agreed to remove it completly in Z cycle 14:37:36 slaweq: thanks, so we discussed, and set it to Z 14:37:37 as we merged in OSC possibility to pass custom parameters to Neutron 14:37:47 amotoki: that message has been there way longer that 2 cycles 14:37:49 ah, I hadn't seen that, but that looks like a good path forward 14:37:49 which was last missing thing AFAIR 14:38:12 mlavalle: nope, it was slightly different and said that it will be removed "in the future" 14:38:21 mlavalle: the message was updated in Xena cycle and it now contains when it plans to be dropped. 14:38:25 not it says that it will be removed in "Z cycle" 14:38:30 ok, so in Z we can remove the CLI code from neutronclient 14:38:36 ++ 14:38:38 +1 14:38:43 cool 14:40:18 ok, for now I think I will ask heat folks if it is possible to have sdk as client for some feature, and come back with result for that 14:40:33 thanks for the discussion 14:40:45 any other topics to discuss? 14:41:28 well I added a topic to the CI meeting, but if we have time now we can discuss here 14:41:38 about neutron-trunk testing in grenade 14:42:11 yeah, that is interesting 14:42:24 where I argue that it would make sense to move the service definition for that from neutron's devstack plugin into devstack proper 14:42:39 gmann is working on some patches to have trunk enabled 14:42:59 iiuc that has already been merged 14:43:11 frickler: ok, I missed that 14:43:13 frickler are You saying to move https://github.com/openstack/neutron/blob/master/devstack/lib/trunk to devstack repo? 14:43:14 frickler: lajoskatona those are merged on master but not for stable 14:43:28 but I would like to get grenade away from using the neutron devstack plugin 14:43:39 slaweq: yes, that and some wrapping code 14:43:58 https://review.opendev.org/q/topic:%22bug%252F1945346%22+(status:open%20OR%20status:merged) 14:44:25 and those are WIP due to nova bug https://bugs.launchpad.net/nova/+bug/1912310 14:44:25 gmann: thanks 14:44:44 one question is: what about the other new features, will more of them become "standard" soon? 14:44:56 then this may be a lost cause anyway 14:46:03 not sure when feature become standard :-) 14:46:14 frickler: lajoskatona slaweq and on master we run trunk test as extensions is set as 'All' (enable everything) 14:46:18 frickler: tbh I don't know about any discussion to make it "standard feature" 14:46:37 to me too, it make sense to move to lib/trunk to devstack side 14:46:41 lajoskatona: my definition would be: "when other projects want to test them in the default grenade job" 14:47:00 or possibly default tempest job even 14:47:15 +1 14:47:17 frickler: ok, that makes sense 14:47:35 gmann: but wasn't that "ALL" in extensions list kind of bug? 14:47:45 that should be part of the interop dicsussion perhaps 14:47:59 if we will have it like that we would need to move also other things to devstack repo as they would all be "standard features" 14:48:01 no? 14:48:02 slaweq: well, on master we want to test everything while development/release itself right? 14:48:43 slaweq: either move them, too, or accept that the neutron plugin is part of the standard setup 14:48:44 and anything under-development can be added in disable list 14:49:42 but then the question would be: what goes into devstack/lib/neutron* at all? 14:50:18 frickler: we can move things which are there for at least couple of cycles and are considered as "stable" to devstack repo 14:50:20 frickler: that's a good question 14:50:22 like trunk, qos 14:50:32 port_forwarding etc. 14:50:37 agree. perhaps once a feature is complete it is better to move their testing from neutron-specific to tempest/devstack. 14:50:40 I can't say where the border should be as neutron CI is quite big 14:51:11 in fact I think that we are adding things to neutron devstack plugin as it's easier and faster for us 14:51:27 but now tempest runs tests wit ovn only, no? 14:51:30 and due to that (mgiht be) we kept trunk disabled in all stable for no reason and testing on master only 14:51:35 but we can consider moving things to devstack repo once they are finished, e.g. next cycle after something was introduced 14:51:54 lajoskatona: yes, whatever devstack is default 14:51:54 and neutron-tempest-lugin has jobs for other backend, ovs, linuxbridge? 14:52:41 there was some issue with debian and ovn iirc 14:52:46 lajoskatona: I think we are discussing tests themselves rather than job definitions 14:52:57 yeah if we move part of neutron devstavk-plugin to core devstack we should still has specific job definitons for not-ovn jobs.... 14:53:15 amotoki: true 14:53:28 https://review.opendev.org/c/openstack/devstack/+/789083/20/.zuul.yaml#90 14:54:11 lajoskatona: I think that those are unrelated things really 14:55:40 So the suggestion is to move trunk related code from neutron devstack plugin to devstack itself ? 14:55:44 o.k., so does someone want to do the neutron-trunk move as a first step? 14:56:00 I can do this 14:56:29 That can be a good start and based on that we can see if we need to move anything else 14:56:43 slaweq: thanks 14:56:44 and then maybe have a topic at the ptg to see what other things should be moved next 14:56:51 +1, indeed 14:56:57 ++ 14:56:57 +1 14:56:59 +1 14:57:01 +1 14:57:17 gmann: is there any criteria to have backend-specific things in devstack? 14:57:39 we already have several backend-specific things in devstack like linuxbridge. 14:57:52 amotoki: nothing as such as long we as we are testing those somewhere 14:57:58 ovn, ovs too 14:58:16 thanks 14:58:21 I remember we have for cinder too 14:58:29 maybe one could actually move lb back into the neutron plugin, now that it isn't widely tested anymore? 14:59:00 frickler: I can add it to my todo list but not with high priority for sure 14:59:12 those can be checked 14:59:28 ok we can close the meeting I think 14:59:36 See you next week 14:59:40 #endmeeting