14:00:25 <slaweq> #startmeeting networking
14:00:25 <openstack> Meeting started Tue Mar 24 14:00:25 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:28 <openstack> The meeting name has been set to 'networking'
14:00:34 <njohnston> o/
14:00:40 <lajoskatona> o/
14:00:48 <haleyb> o/
14:00:55 <rubasov> o/
14:01:31 <bcafarel> \o
14:02:14 <slaweq> ok, lets start
14:02:18 <slaweq> #topic Announcements
14:02:31 <slaweq> according to https://releases.openstack.org/ussuri/schedule.html next important dates are:
14:02:32 <slaweq> Final release for non-client libraries - week of March 30th,
14:02:38 <slaweq> Ussuri-3 (feature freeze) - week of April 6th
14:02:57 <slaweq> so final release of non-client libraries is next week
14:03:36 <slaweq> I think we should review what is missing and needed there still and get it merged this or early next week
14:03:49 <slaweq> and then we will prepare releases next week with amotoki
14:05:20 <slaweq> if You have any patches waiting in review queue which You want to include in this final release of any lib, please ping me and tell me what patch You need
14:05:41 <ralonsoh> hi
14:06:17 <slaweq> and then in 2 weeks we have Ussuri-3 and feature freeze
14:06:45 <slaweq> so we should now focus also on reviewing patches related to RFEs which we want to deliver in Ussuri
14:07:05 <slaweq> most of them I think have set review-priority +1
14:07:46 <slaweq> any questions/comments about those dates?
14:08:10 <njohnston> looks good to me
14:08:55 <slaweq> ok, so next one
14:09:14 <slaweq> also about dates, according to https://governance.openstack.org/election/ PTL nomination period starts on Mar 24th which is today
14:09:30 <slaweq> so if someone wants to candidate - this is week of nominations :)
14:09:52 <slaweq> next announcement
14:10:01 <slaweq> Victoria PTG in Vancouver is cancelled https://www.openstack.org/events/opendev-ptg-2020/
14:10:07 <slaweq> If You want to help to organize virtual PTG, please add Your name in https://etherpad.openstack.org/p/Virtual_PTG_Planning
14:10:57 <slaweq> we will need to find some way to arganize virtual ptg
14:11:04 <slaweq> so no team dinner this time :(
14:11:36 <njohnston> This time I won't be the only one participating remotely :-)
14:11:44 <slaweq> njohnston: true :)
14:12:00 <njohnston> I think it will be different but it will have benefits
14:12:05 <bcafarel> virtual team dinner then?
14:12:27 <slaweq> bcafarel: I'm not sure if that will work fine but we can try :)
14:12:39 <amotoki> someone can have beer from the morning :)
14:12:48 <slaweq> :)
14:13:01 <amotoki> sorry for late
14:13:22 <slaweq> amotoki: and there will be excuse for that at least :D
14:14:04 <slaweq> and also speaking about Victoria (Virtual) PTG, we have Victoria PTG planning etherpad: https://etherpad.openstack.org/p/neutron-victoria-ptg
14:14:13 <slaweq> please add Your ideas about topics there
14:14:30 <slaweq> and thx to all who already added some proposals there
14:14:30 <njohnston> I rather like the way Ironic is doing their Unconference.  I like the PTG idea but if we go back to the old midcycle concept then we can space things out so people involved in multiple projects dont have to juggle schedules
14:15:56 <slaweq> njohnston: but are You talking about virtual midcycle or "real" ones?
14:16:15 <njohnston> well in these days it would be a virtual midcycle
14:17:09 <slaweq> njohnston: I guess there is already some discussion about that in TC, right?
14:18:19 <njohnston> slaweq: Yeah, let me wait for those ideas to get more fleshed out and I'll being the topic back at that point
14:18:53 <amotoki> we are remote so we can split the event into small sessions per topic and coordinate schedules even over multiple weeks. we don't necessarily need to have sessions in consecutive days.
14:19:06 <lajoskatona> I think the worst with a virtPTG is that for days we have to be active for the night
14:19:29 <njohnston> lajoskatona: It is rough for sure
14:19:42 <lajoskatona> so perhaps after identifiing the topics starting smaller meetings for the ones that are not fixed in mails or on irc can be better
14:20:02 <slaweq> lajoskatona: that indeed sounds like good idea, at least for now
14:20:11 <slaweq> lets see how it will evolve in next weeks
14:20:41 <slaweq> I knot gibi already proposed something for nova so we can follow them with some ideas probably :)
14:20:44 <lajoskatona> ok
14:21:37 <slaweq> ok, lets move on
14:21:39 <slaweq> #topic Blueprints
14:21:44 <slaweq> Blueprints for Ussuri-3: https://launchpad.net/neutron/+milestone/ussuri-3
14:21:49 <slaweq> any updates about them?
14:23:47 <slaweq> I wanted to ask about https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge - Convergence of ML2+OVS+DVR and OVN
14:24:47 <slaweq> last time we said that last missing patches for this are  https://review.opendev.org/#/c/711317/ and https://review.opendev.org/#/c/702247/
14:25:09 <slaweq> but is https://review.opendev.org/#/c/711317/ needed to mark BP as done? this has reported separate bug
14:25:19 <slaweq> and patch isn't linked with BP at all
14:25:24 <slaweq> haleyb: what do You think?
14:26:04 <ralonsoh> slaweq, this patch is still not finished
14:26:06 <haleyb> slaweq: i think getting https://review.opendev.org/#/c/702247/ would close it, and it was just updated, i'll review
14:26:22 <haleyb> the rest are follow-ons and bug fixes i think
14:26:43 <slaweq> haleyb: thx, that's exactly my opinion also
14:27:32 <slaweq> for other BPs, I did some progress on https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
14:27:37 <slaweq> Patches waiting for review now: https://review.opendev.org/#/q/status:open+topic:bp/enginefacade-switch
14:28:47 <slaweq> and about https://blueprints.launchpad.net/neutron/+spec/metadata-over-ipv6 - please all, review spec for this https://review.opendev.org/#/c/315604/
14:28:48 <slaweq> :)
14:29:18 <ralonsoh> slaweq, bence found a possible architecture error in the spec
14:29:28 <ralonsoh> while doing a POC
14:29:33 <rubasov> just commented before this meeting
14:29:52 <slaweq> rubasov: ralonsoh: yes, I just saw it
14:30:00 <slaweq> I will read after this meeting
14:30:35 <rubasov> please check if you also think it is because the kernel behaves differently
14:31:47 <slaweq> and that's all update about BPs from me today
14:32:37 <slaweq> if there is nothing else, lets move on
14:32:39 <slaweq> #topic Community goals
14:32:55 <slaweq> here currently we have only not finished IPv6-only testing goal
14:33:05 <slaweq> but I didn't had time to work on it this last week
14:33:12 <haleyb> was the unittest.mock change a community goal?
14:33:25 <njohnston> haleyb: no
14:33:27 <ralonsoh> that was a recommendation
14:33:30 <slaweq> haleyb: not yet for sure
14:33:34 <slaweq> maybe for V cycle
14:33:46 <njohnston> AFAIK noone has proposed it for V cycle
14:33:48 <haleyb> ok, i'll mention it in open agenda then
14:34:33 <slaweq> njohnston: any updates about migration to Zuul v3 which is Victoria goal?
14:35:06 <njohnston> The only change in the field I know about is https://review.opendev.org/#/c/703949/ for networking-bagpipe
14:35:28 <njohnston> lajoskatona: Have you gotten a start on converting networking-odl to zuulv3?
14:35:47 <lajoskatona> yes, but I have to restart as that was month ago
14:35:53 <njohnston> lajoskatona: thinking specifically about https://opendev.org/openstack/networking-odl/src/branch/master/.zuul.d/jobs.yaml#L240 to EOF
14:36:26 <lajoskatona> yes I have an old patch for that somewhere
14:36:36 <njohnston> lajoskatona: OK, hopefully those jobs wont be too bad, they look pretty straightforward
14:36:37 <lajoskatona> I refresh it and ask around in odl community
14:36:40 <njohnston> thanks
14:36:48 <slaweq> lajoskatona: and do You need help with https://review.opendev.org/#/c/703949/ ?
14:36:50 <njohnston> and I don't know if we have anyone who can comment on midonet
14:37:18 <njohnston> with odl and midonet and that one bagpipe change I think we're complete
14:37:26 <lajoskatona> I think now that horizon is stabilized with pyScss2 those can be pushed forwards
14:38:41 <slaweq> if You would need help with it lajoskatona, You can ping me
14:38:45 <slaweq> next topic
14:38:47 <slaweq> #topic Bugs
14:38:55 <lajoskatona> slaweq: thanks, I check the fresh resulst and come back
14:39:05 <slaweq> I was on bug deputy. Summary http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013510.html
14:39:26 <slaweq> from what I wanted to highlight here is
14:39:33 <slaweq> *are
14:39:35 <slaweq> Two high bugs related to CI which we should take a look: https://bugs.launchpad.net/neutron/+bug/1867936 https://bugs.launchpad.net/neutron/+bug/1868237
14:39:37 <openstack> Launchpad bug 1867936 in neutron "test_update_delete_extra_route failing due to timeout when creating subnets" [High,Confirmed]
14:39:38 <openstack> Launchpad bug 1868237 in neutron "[tempest] Error in "test_multicast_between_vms_on_same_network" test case" [High,Confirmed]
14:39:59 <slaweq> both don't have assignment yet, so if anyone have some cycles to take a look, that would be great
14:40:46 <slaweq> and also https://bugs.launchpad.net/neutron/+bug/1868137 which rubasov is already looking at but maybe someone more familiar with ovn driver could also take a look
14:40:47 <openstack> Launchpad bug 1868137 in neutron "default geneve overhead is not set high enough for ovn" [Medium,Confirmed]
14:41:35 <slaweq> any other bugs You want to discuss with the team today?
14:42:32 <haleyb> slaweq: am i deputy this week?
14:42:52 <slaweq> haleyb: no, this week hongbin is deputy
14:43:02 <slaweq> Your turn is next week
14:43:07 <haleyb> phew!
14:43:26 <slaweq> :)
14:43:50 <bcafarel> next week plan: create all the bugs!
14:44:02 <slaweq> LOL
14:44:18 <slaweq> we will do competition: who can open more bugs next week :P
14:44:55 <haleyb> i can close them just as fast :)
14:45:04 <slaweq> haleyb: :D
14:45:29 <slaweq> ok, lets move on to the last topic for today
14:45:31 <slaweq> #topic On Demand Agenda
14:45:49 <slaweq> anything else You want to discuss today/
14:45:51 <slaweq> ?
14:45:53 <haleyb> i have one
14:45:58 <slaweq> go on haleyb
14:46:23 <haleyb> along the recommendation of moving to unittest.mock, and other projects doing it i created https://review.opendev.org/#/c/711579/
14:46:48 <haleyb> it found some bugs which are in the related change section
14:46:54 <slaweq> that is huge patch :)
14:47:10 <haleyb> yes, very big, mostly one-liners luckily
14:47:44 <haleyb> but it's now failing in the functional tests and needs some debugging, was wondering if i should split it up into unit and functional pieces to get one merged
14:48:13 <ralonsoh> +1 for this
14:48:15 <njohnston> haleyb: I think that is a good idea
14:48:18 <slaweq> +1
14:49:06 <bcafarel> I though it was only UT in that review, looks like I missed a few lines in that long list?
14:49:34 <slaweq> bcafarel: at first glance it seems for me that functional tests may fail due to https://review.opendev.org/#/c/711579/3/neutron/tests/base.py
14:49:45 <bcafarel> but +1 on the idea, with fixes in now for UT it is mostly rename/reorder and it looked good to me when I checked
14:49:46 <haleyb> ok, i'll get that one passing and propose another follow-on - i think it's the change in test_base.py? at least i thought it was the functional tests failing on a mock
14:49:48 <slaweq> as those tests inherits from this too
14:49:57 <bcafarel> ah true!
14:50:00 <haleyb> slaweq: ah yes, that's it
14:50:25 <haleyb> so really it's the patches it's depending on that need review
14:51:56 <bcafarel> ok https://review.opendev.org/#/c/713350/ is a bit larger too
14:52:38 <haleyb> go big or go home :)
14:52:48 <haleyb> i
14:52:54 <haleyb> i'm padding my stats
14:52:59 <slaweq> :)
14:53:00 <bcafarel> :)
14:53:22 <ralonsoh> and the revert of https://review.opendev.org/#/c/711158?
14:53:34 <ralonsoh> (this is the last related patch)
14:53:35 <haleyb> ralonsoh: i was going to mention that one too
14:53:39 <ralonsoh> sorry
14:53:44 <haleyb> np
14:54:09 <haleyb> looking at that again last night, looks like the int_br changes should be reverted for now, but the tun_br one is ok
14:54:27 <haleyb> liuyulong: don't know if you're here but is that ok? ^^
14:54:44 <haleyb> or we just revert and re-do
14:55:24 <slaweq> I don't understand, why we need revert of https://review.opendev.org/#/c/711158 ?
14:55:30 <haleyb> that was another change brought by the unittest.mock change, so maybe being too aggressive
14:55:40 <ralonsoh> we use only native implementation
14:55:52 <ralonsoh> why can't we remove deferred?
14:56:37 <haleyb> i think there is still a small piece of code using ofctl in the int br, liu pointed it out i think
14:57:08 <ralonsoh> https://review.opendev.org/#/c/711158/2/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py@2082
14:57:14 <ralonsoh> I'll recheck that
14:57:29 <ralonsoh> but the add_flow command will depend on the implementation used
14:57:34 <ralonsoh> and now we have only native
14:57:56 <slaweq> so shouldn't we get rid of this ofctl code instead of reverting Your patch?
14:58:16 <haleyb> https://github.com/openstack/neutron/blob/master/neutron/agent/common/ovs_lib.py#L422-L475 was the code
14:58:32 <ralonsoh> yes, you are right
14:58:37 <haleyb> has a run_ofctl() call :(
14:58:41 <ralonsoh> slaweq, this is not that simple
14:58:50 <liuyulong> https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_030/711158/2/gate/neutron-tempest-plugin-scenario-openvswitch/0301da3/controller/logs/screen-q-agt.txt
14:58:56 <ralonsoh> slaweq, https://bugs.launchpad.net/networking-sfc/+bug/1853171
14:58:57 <openstack> Launchpad bug 1853171 in neutron "Deprecate and remove any "ofctl" code in Neutron and related projects " [Medium,In progress]
14:59:07 <liuyulong> tons of ovs-ofctl here in the log
14:59:09 <slaweq> ralonsoh: ok, now I remember :)
14:59:52 <ralonsoh> liuyulong, you are right: there are still some OF handled by ofctl
15:00:06 <slaweq> ok, we are running out of time
15:00:17 <slaweq> so lets continue this in neutron channel if needed
15:00:23 <slaweq> thx for attending the meeting
15:00:28 <slaweq> #endmeeting