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