21:00:20 <slaweq> #startmeeting networking
21:00:22 <openstack> Meeting started Mon Jun 22 21:00:20 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:25 <openstack> The meeting name has been set to 'networking'
21:00:25 <slaweq> hi
21:00:28 <njohnston> o/
21:00:51 <amotoki> hi
21:01:40 <slaweq> lets wait few more minutes for more people
21:02:21 <bcafarel> o/
21:02:48 <slaweq> ok, I think we can start as I don't expect there will be more people here today (tonight)
21:02:50 <slaweq> #topic Announcements
21:03:25 <slaweq> Last week was Victoria-1 milestone
21:03:28 <slaweq> Next milestone is Victoria-2 in the week of July 27th
21:04:14 <slaweq> I think we should really focus now on reviewing some specs and implemantation of the approved BPs to get some work done in this cycle :)
21:04:28 <slaweq> next one
21:04:29 <slaweq> Neutron-fwaas is now deprecated in master branch - there will be no new releases of it in Victoria, code is removed from the repo
21:04:38 <slaweq> and the same for neutron-fwaas-dashboard
21:05:04 <amotoki> sorry for missing the later drivers meeting. I did not feel good these weeks and am slowing down activities unfortunately.
21:05:19 <slaweq> amotoki: sure, no problem at all :)
21:05:22 <amotoki> I saw the discussion on API and CLI on neutron-fwaas in the meeting log.
21:05:53 <amotoki> I had some question on maintenance of fwaas API, but it can be deferred to the last of the meeting.
21:07:24 <slaweq> amotoki: ok, lets talk about it in On demand agenda
21:07:28 <slaweq> good for You?
21:07:31 <amotoki> slaweq: sure
21:08:14 <slaweq> thx
21:08:30 <slaweq> according to fwaas deprecation, there is still couple of patches not merged https://review.opendev.org/#/q/status:open+branch:master+topic:retire-neutron-fwaas
21:08:48 <slaweq> but those are all related to some projects which were using fwaas in ci jobs
21:09:01 <slaweq> all governance work is done already
21:09:19 <slaweq> ok, next announcement
21:09:23 <slaweq> Networking-midonet - based on feedback from the project's core team, I'm going to propose write an email to call for volunteers and if there will be no people who wants to maintain it before Victoria-2 I will deprecate it in same way as fwaas in Ussuri cycle,
21:10:13 <amotoki> I think we need to distinguish the usage of "deprecation" and "removal".
21:10:24 <amotoki> "deprecation" means "future removal".
21:10:27 <slaweq> amotoki: right
21:10:35 <amotoki> I think neutron-fwaas is "removed".
21:10:51 <slaweq> yes, I was thinking about removal it too
21:11:13 <slaweq> but then I found out that if we are still keeping stable branches, it's deprecation from governance PoV
21:11:26 <amotoki> yeah, correct.
21:11:41 <slaweq> and I think we should do it like that to not break existing stable branches where fwaas is delivered already
21:13:01 <amotoki> totally agree
21:13:07 <slaweq> so amotoki how You would call what we want to do with networking-midonet now?
21:13:46 <slaweq> it is basically just an Docs warning so IMO we can write that "it will be deprecated for future removal in next cycle" or something like that
21:13:54 <slaweq> would it be ok for You?
21:14:02 <slaweq> so something like "pre-deprecate" :)
21:14:19 <amotoki> I think we cannot call it as "deprecated" and "removal" either. we have no maintenaers, so we need to say "volunteer for maintenance is needed. otherwise it will be derpecated for removal"
21:14:41 <slaweq> sounds good
21:14:46 <amotoki> slaweq: I think we are in the same page.
21:15:06 <slaweq> I will write it like that in the "call for volunteers" email this week
21:15:10 <slaweq> thx amotoki
21:15:26 <slaweq> ok, next announcement
21:15:34 <slaweq> Virtual OpenDev, next week is first virtual event "Large-scale Usage of Open Infrastructure Software": https://www.openstack.org/events/opendev-2020/
21:15:46 <slaweq> please register if You want to participate in this event
21:15:51 <slaweq> (I will :))
21:16:14 <slaweq> and that's all anouncements for today from me
21:16:23 <slaweq> do You have anything else to announce to the team?
21:16:31 <amotoki> nothing from me
21:17:34 <slaweq> btw. agenda for this virtual event is here: https://www.openstack.org/events/opendev-2020/opendev-schedule
21:17:37 <slaweq> ok, lets move on
21:17:45 <slaweq> #topic Blueprints
21:18:01 <slaweq> BPs for Victoria-2: https://launchpad.net/neutron/+milestone/victoria-2
21:18:16 <slaweq> do You have updates about any of them?
21:18:40 <slaweq> I promissed rubasov to review his Metadata over IPv6 patches this week but I didn't had time
21:18:46 <slaweq> I will try to play with it this week
21:21:08 <slaweq> ok, I guess that there is no any other updates about BPs for today
21:21:27 <slaweq> so lets move on to the next topic
21:21:33 <slaweq> #topic Community goals
21:21:34 <bcafarel> people were too busy fixing gates
21:21:40 <slaweq> bcafarel++ true
21:21:42 <slaweq> :)
21:21:50 <slaweq> Migrate to zuulv3
21:22:24 <slaweq> according to the current state of networking-midonet, I think we can move it out from the list of projects which needs to be done to accomplish that goal
21:22:27 <slaweq> what do You think?
21:23:05 <bcafarel> +1 no need to work on it if we remove it from our radar
21:24:12 <amotoki> +1 unless we find volunteers luckily
21:25:25 <slaweq> ok
21:25:45 <njohnston> +1
21:25:46 <slaweq> so with that we are just missing few grenade jobs to be switched and we will be done with all :)
21:26:22 <slaweq> ok, lets move on
21:26:26 <slaweq> next community goal
21:26:28 <slaweq> Migrate CI/CD jobs to new Ubuntu LTS Focal
21:26:49 <slaweq> today I pushed patch https://review.opendev.org/737370 to see how neutron-tempest-dvr-ha-multinode-full will work with focal
21:27:04 <slaweq> but for now I think that devstack patch has to be fixed first
21:27:15 <slaweq> and no other updates on that one from me
21:28:17 <bcafarel> lajos rebased functional jub one https://review.opendev.org/#/c/734304/4 today but it looks like it needs another rebase
21:29:13 <slaweq> yep
21:29:28 <slaweq> ok, I think we can move on
21:29:32 <slaweq> #topic Bugs
21:29:41 <slaweq> bcafarel was our bug deputy last week
21:29:49 <slaweq> report is here http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015562.html
21:29:59 <slaweq> bcafarel: anything You want to highlight now?
21:30:25 <bcafarel> not that much, most bugs are well underway
21:30:56 <bcafarel> I highlighted the 2 without owner, https://bugs.launchpad.net/neutron/+bug/1884067 would be good to fix
21:30:56 <openstack> Launchpad bug 1884067 in neutron "[API] Filtering by fields not allowed to see is possible for regular users" [High,Confirmed]
21:31:11 <bcafarel> (well https://bugs.launchpad.net/neutron/+bug/1884254 too but it is for less common situations)
21:31:11 <openstack> Launchpad bug 1884254 in neutron "Restart of neutron-ovs-agent may cause data plane breakage" [Low,Confirmed]
21:31:30 <amotoki> I am just commenting the first one.
21:31:45 <slaweq> thx amotoki - I just wanted to ask You to take a look at that one :)
21:32:02 <amotoki> it looks like we need to apply policy for filter arguments but it may need more work.
21:32:29 <slaweq> yes, and I marked it as high as potentially it may cause some data leak even
21:32:52 <slaweq> if user will know e.g. hostname he can find out what ports are on this host (which regular used shouldn't now)
21:32:52 <amotoki> yeah. If we don't see any security issue, I think we can lower the priority of it.
21:33:14 <slaweq> maybe it's not very serious problem as he would need to know exact hostname first
21:33:22 <slaweq> so maybe "medium" would be better
21:34:48 <amotoki> agree. anyway I will add a comment.
21:34:58 <slaweq> thx amotoki
21:35:21 <slaweq> the other one is rather low priority IMO as it's corner case with broken rabbitmq when the issue can happen
21:35:50 <slaweq> any other bugs You want to discuss today?
21:36:30 <slaweq> ok, I guess this means "no" :)
21:36:34 <slaweq> so lets move on
21:36:50 <slaweq> this week I'm bug deputy
21:36:59 <slaweq> I already sent email to myself with a reminder :P
21:37:10 <bcafarel> :)
21:37:14 <amotoki> :)
21:37:20 <slaweq> next week hongbin will be bug deputy
21:37:32 <slaweq> I will ping him this week about that
21:37:52 <slaweq> also, regarding our gate
21:38:06 <slaweq> I proposed recently patch https://review.opendev.org/#/c/735608/ as follow up from the PTG, please review it if You will have few minutes
21:38:27 <slaweq> it's new CI job with neutron-lib from master branch, as we discussed during the virtual PTG
21:38:50 <slaweq> ok, that's all about bugs for today
21:38:58 <slaweq> #topic On Demand agenda
21:39:08 <slaweq> amotoki: lets talk about Your concerns about fwaas
21:39:17 <amotoki> sure
21:39:33 <amotoki> I am okay to keep the FWaaS API in neutron-lib but it raised me a question. How can we maintain it?
21:39:45 <amotoki> If someone would like to propose some change (for example from the third party impl perspective), what should we do? Or is it frozen?
21:39:52 <amotoki> that's my question.
21:40:17 <slaweq> that's good question :)
21:40:39 <amotoki> one idea is just to note that the FWaaS API is frozen to keep the last state of FWaaS.
21:41:15 <amotoki> if someone would like to enhance the API, it might be a good timing to resume the work in something like x/neutron-fwaas
21:42:15 <njohnston> And as such we would require a functional implementation of the API definition as-is before we would ratify an extension of the API as it stands in neutron-lib
21:42:41 <slaweq> amotoki: I think it's good idea to say that this api-ref is frozen now
21:43:04 <slaweq> if someone want's to enhance it - they can revive project and keep new api there probably
21:43:31 <slaweq> concern raised on last drivers meeting was about current api and its support in e.g. OSC
21:43:47 <slaweq> and because of that we said that we can keep this API-ref in neutron-lib stil
21:43:50 <slaweq> *still
21:44:15 <slaweq> but I don't see any reason why we should accept new API for fwaas as an official API for this project
21:44:51 <amotoki> agree
21:45:27 <amotoki> OSC fwaas commands are provided by the OSC nuetronclient plugin, so it is still under the neutron team
21:45:49 <amotoki> in addition, OSC team tries to support older APIs like nova-network, so it might not be a problem.
21:47:32 <njohnston> amotoki: Will that still be true if we deprecate python-neutronclient?
21:47:33 <slaweq> amotoki: yes, but the other reason why IMO we should keep it for now is that api-ref in neutron-lib is "branchless" and we still have stable branches
21:48:46 <amotoki> slaweq: yes, it's true. one idea is to move removed APIs to some separate page.
21:49:31 <amotoki> njohnston: during the OSC migration, the basic policy discussed is that we have commands for advanced services as the OSC plugin.
21:49:48 <amotoki> njohnston: "deprecation" is only applied to "neutron" CLI in my understanding.
21:50:25 <slaweq> amotoki: I agree, IMO we talked about that in the past and we said that python bindings in neutronclient aren't deprecated
21:50:25 <amotoki> njohnston: python-neutronclient repo still has OSC plugin and python bindings for example used by nova.
21:50:36 <slaweq> and we still accept new patches there all the time
21:50:47 <amotoki> exactly
21:54:08 <njohnston> +1
21:54:20 <slaweq> ok, so I think that adding note that this API ref is now "frozen" will be good idea
21:54:26 <slaweq> are You ok with that?
21:54:34 <amotoki> +1
21:55:13 <slaweq> ok
21:55:15 <slaweq> thx
21:55:26 <slaweq> so I think we are done for today
21:55:35 <slaweq> any last minute topics to discuss?
21:56:29 <bcafarel> none from me
21:56:35 <amotoki> me neither
21:56:36 <njohnston> nope
21:56:38 <slaweq> ok
21:56:44 <slaweq> thx for attending the meeting
21:56:51 <njohnston> o/
21:56:51 <slaweq> see You all online
21:56:54 <bcafarel> o/
21:56:55 <amotoki> o/
21:56:55 <slaweq> and have a great week
21:56:57 <slaweq> o/
21:57:00 <slaweq> #endmeeting