14:01:19 <slaweq> #startmeeting networking
14:01:20 <openstack> Meeting started Tue May 25 14:01:19 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:23 <openstack> The meeting name has been set to 'networking'
14:01:25 <mlavalle> o/
14:01:30 <slaweq> hi
14:01:32 <obondarev> hi
14:01:35 <ralonsoh> hi
14:01:53 <bcafarel> o/
14:02:15 <njohnston> o/
14:02:24 <slaweq> #topic announcements
14:02:33 <slaweq> Xena cycle calendar https://releases.openstack.org/xena/schedule.html
14:02:41 <slaweq> this week is Xena-1 milestone already
14:02:45 <slaweq> (time flies :))
14:02:53 <slaweq> Xena-2 will be week of the Jul 12
14:03:45 <lajoskatona> Hi
14:04:23 <slaweq> Nomination for Y names' proposals is still open http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022383.html
14:04:35 <slaweq> if You have any ideas, You can propose it there
14:04:59 <slaweq> next one
14:05:15 <slaweq> OpenStack SDK - r1.0 feature branch will be created, we should now propose new patches to that branch and cherry-pick for master: http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022535.html
14:05:35 <slaweq> so if You plan to propose something to SDK, please follow the process mentioned there
14:05:51 <slaweq> and ask on the #openstack-sdks channel in case of any doubts :)
14:06:13 <slaweq> and that's all annuncements from me for today
14:06:19 <slaweq> do You have anything else to add?
14:06:51 <bcafarel> OVN back as devstack default? I think I saw that merged this morning :)
14:07:21 <slaweq> bcafarel: oh, really? I probably missed it
14:07:36 <lajoskatona> https://review.opendev.org/c/openstack/devstack/+/791436
14:07:48 <lajoskatona> I think this one
14:08:05 <bcafarel> thanks I was looking up in my history, yes this is the one I saw
14:08:11 <slaweq> great :)
14:08:14 <slaweq> thx for the info
14:09:13 <obondarev> are we sure all CI jobs that are supposed to be testing OVS not testing OVN now? :)
14:09:48 <ralonsoh> we should have the neutron-tempest-plugin problems again
14:09:54 <slaweq> obondarev: I think we should check it to be sure
14:10:03 <ralonsoh> we'll need https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/791255 and https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/791148
14:11:58 <slaweq> ralonsoh: thx for the links
14:12:03 <lajoskatona> and these for some stadium: https://review.opendev.org/q/topic:%2522ovn-devstack%2522+(status:open+OR+status:merged)+owner:%2522lajos+katona%2522
14:12:42 <slaweq> lajoskatona: thx for the links too
14:12:52 <amotoki> one question: whta happens if some GRE user uses neutron-tempest-tests?
14:12:56 <slaweq> I already +2'ed all of them, so please others check them too :)
14:13:58 <lajoskatona> amotoki: What do you mean, downstream, or from opendev zuul?
14:13:59 <slaweq> amotoki: those trunk tests should be skipped in such case
14:14:30 <amotoki> slaweq: because the upstream testing env does not support it?
14:14:50 <ralonsoh> we can always switch to OVS, if needed: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/791417
14:15:07 <ralonsoh> or create a new CI job (not recommended)
14:15:27 <slaweq> yes, at least according to https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/791255/3/neutron_tempest_plugin/api/test_trunk.py#250 IIUC
14:16:14 <amotoki> slaweq: okay. I have no strong opinion on it.
14:16:57 <amotoki> if GRE users want to test these in their deployments, they should write their own tests. okay.
14:17:14 <amotoki> I am not sure we really have these needs though.
14:17:16 <slaweq> amotoki: but if someone is running those tests on env with GRE enabled, then it's not OVN backend
14:17:46 <amotoki> slaweq: yes
14:17:49 <amotoki> I am looking at https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/791255/3/neutron_tempest_plugin/api/test_trunk.py#250
14:17:58 <slaweq> ok, I see Your point now
14:18:07 <slaweq> we should make check in that L250 smarter
14:18:12 <amotoki> I think it is part of the API tests, so they are backend agnostic.
14:18:14 <slaweq> and aware of backend probably somehow
14:20:22 <slaweq> I will open LP and will try to make it smarter
14:20:33 <slaweq> but for now let's go with ralonsoh's patch to unblock the gate
14:20:36 <slaweq> is that ok for You?
14:20:45 <amotoki> slaweq: works for me :)
14:20:48 <slaweq> thx
14:20:56 <slaweq> and thx for raising that here
14:21:43 <slaweq> ok, let's move on then
14:21:54 <slaweq> #topic Blueprints
14:22:10 <slaweq> I moved opened BPs to Xena-2: https://bugs.launchpad.net/neutron/+milestone/xena-2
14:22:20 <slaweq> do You have any updates about any of them?
14:24:10 <slaweq> I have only small update about https://blueprints.launchpad.net/neutron/+spec/secure-rbac-roles
14:24:27 <slaweq> there is only few patches opened in the list https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open+project:openstack/neutron
14:24:32 <slaweq> thx for all reviews
14:24:43 <slaweq> and please check those few which are missing approval
14:25:22 <slaweq> after that I will check how to switch to new defaults in the devstack, so maybe we will be able to have one job running with them
14:25:32 <slaweq> but I didn't explored yet how to do it
14:27:33 <lajoskatona> Please review these (I was disconnected in the meantime....) : https://review.opendev.org/c/openstack/neutron-specs/+/785236 https://review.opendev.org/c/openstack/neutron-specs/+/783791 https://review.opendev.org/c/openstack/neutron-specs/+/767337
14:27:34 <slaweq> regarding liuyulong's BP https://blueprints.launchpad.net/neutron/+spec/distributed-dhcp-for-ml2-ovs, we have also only few patches left https://review.opendev.org/q/topic:%22bp%252Fdistributed-dhcp-for-ml2-ovs%22+(status:open%20OR%20status:merged)
14:28:23 <slaweq> thx lajoskatona for the links
14:28:54 <lajoskatona> slaweq: Good that You mention it, in https://review.opendev.org/c/openstack/neutron/+/776567/22/neutron/conf/plugins/ml2/drivers/ovs_conf.py there's a new cfg option to enable ipv6 dhcp,
14:30:07 <lajoskatona> I have some concenr as now IPv6 works out of the box (of course its more difficult as we need the infrastructure and othere cfg options) so that forks the API between "traiditonal" dhcp in Neutron and the new OVS based dhcp
14:30:50 <lajoskatona> Please check if my feeling regarding this new cfg is incorrect, I can leave with it but we have to guard it with doc in that case
14:32:53 <slaweq> lajoskatona: actually I think it's good point, I'm not sure why this config option is really needed
14:33:17 <slaweq> it should works fine for the IPv6 subnets with DHCP stateful mode
14:33:31 <slaweq> as dhcp agent works currently
14:34:43 <lajoskatona> +1
14:34:49 <obondarev> I guess user might prefer to disable IPv6 DHCP if IPv6 is not used
14:35:02 <obondarev> just to not overload flow tables
14:35:06 <mlavalle> that makes sense
14:35:06 <obondarev> for no good reason
14:35:30 <slaweq> so rules could be added in the lazy way - when first such subnet would appear on the node
14:35:38 <slaweq> but maybe it's not as easy to implement, idk
14:35:42 <slaweq> just thinking loud now
14:36:27 <obondarev> makes sense, but still - even existence of IPv6 subnets may not mean user wants DHCP..
14:36:43 <lajoskatona> Yeah, so perhaps it's the best solution, but than the doc should highlight it
14:36:51 <obondarev> +1
14:36:55 <slaweq> obondarev: but I think about existence of the IPv6 subnet with dhcp mode DHCP stateful
14:37:11 <obondarev> slaweq, got it, agree
14:37:13 <slaweq> which means that user wants to have dhcp v6 provided :)
14:37:35 <slaweq> for SLAAC it's not needed
14:37:45 <slaweq> I'm not sure about dhcpv6-stateless now
14:39:07 <haleyb> that's SLAAC for addressing and DHCP for other bits, so could be needed there
14:39:30 <slaweq> yeah, probably
14:39:31 <obondarev> I think maybe config might be set to True by default, and document the ability to disable it with OVS DHCP extension
14:39:48 <slaweq> obondarev: that can also be possibility
14:39:59 <slaweq> anyway, let's continue that discussion in the gerrit
14:40:00 <lajoskatona> +1
14:40:01 <slaweq> :)
14:40:06 <obondarev> thus we'll preserve current behavior and no need for additional logic
14:40:13 <obondarev> ok :)
14:40:38 <slaweq> let's move on here
14:40:42 <slaweq> #topic Bugs
14:40:50 <slaweq> bcafarel was bug deputy last week. Report http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022674.html
14:41:33 <bcafarel> all good overall (either bugs are already fixed or in progress)
14:42:10 <bcafarel> I just wanted to highlight https://bugs.launchpad.net/bugs/1929197 which would benefit from an OVN check
14:42:11 <openstack> Launchpad bug 1929197 in neutron "[OVN] SB connection unreliable" [Undecided,New]
14:43:07 <ralonsoh> I'll take a look at this one this week
14:43:15 <slaweq> ralonsoh++ thx
14:43:47 <bcafarel> ralonsoh: thanks I could not reproduce it and mentioned change should not have such visible impact, but better safe than sorry :)
14:44:19 <ralonsoh> for sure
14:44:49 <slaweq> thx bcafarel for the report
14:44:59 <slaweq> any other bugs anyone wants to discuss today?
14:45:23 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/792945, please, +2 it again
14:46:49 <slaweq> ralonsoh: done :)
14:46:56 <ralonsoh> thanks
14:48:01 <slaweq> yw :)
14:48:15 <slaweq> thx for proposing patch to unblock the gate so fast :)
14:48:34 <slaweq> this week I'm bug deputy
14:48:37 <obondarev> +1
14:48:39 <slaweq> so I'm already aware :)
14:48:45 <mlavalle> Good
14:49:15 <bcafarel> slaweq: just in case, don't forget to send yourself a reminder :)
14:49:23 <slaweq> bcafarel: sure :D
14:49:36 <slaweq> ok, let's move on
14:49:39 <slaweq> #topic On Demand Agenda
14:49:46 <slaweq> there is one topic here for today
14:49:53 <slaweq> Feedback on Freenode situation http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022675.html
14:50:06 <slaweq> gmann asked about feedback from various teams about what we would like to do
14:50:26 <obondarev> google hangouts :D
14:50:27 <bcafarel> ah yes, quite the hot topic since last week
14:50:30 <slaweq> in the etherpad https://etherpad.opendev.org/p/feedback-on-freenode there are basically 2 options possible
14:50:37 <slaweq> Option1: Ok with the TC's approach of "let's wait more and monitor the situation to make any decision."
14:50:39 <slaweq> Option2: We want to move away from Freenode right now.
14:50:50 <gmann> slaweq: thanks for bringing it
14:51:04 <slaweq> btw. I hope all of You are aware about what is the problem with freenode now, right?
14:51:17 <slaweq> gmann: yw :)
14:51:20 <ralonsoh> yeah
14:51:29 <lajoskatona> yeah
14:51:31 <ralonsoh> IMO, option 2 and swap to another IRC
14:51:44 <slaweq> so I wanted to ask You about Your opinion on that
14:51:55 <slaweq> so I we update that etherpad
14:52:08 <slaweq> *so We can update
14:52:37 <gmann> note, we do not have any finalized platform/network yet
14:52:57 * obondarev votes for opt 1
14:53:06 <gmann> in option1 we are not saying we will stay at freenode but we will wait and see the situation more and then decide
14:53:40 <lajoskatona> +1 on Opt. 1, (the hesitant guy)
14:53:46 <bcafarel> initially I was for option1 (aka we can wait), but some examples of the "new management" + seeing many projects and users already moved changed my mind
14:53:49 <slaweq> maybe I will ask a bit different question - do we have anyone who considers to stop using freenode and current neutron channel until it will not move out from freenode?
14:53:49 <amotoki> I tend to vote for opt 1. From dev perspective, switching to another irc would not impact so much. we can compare more options and get avoid confusion.
14:54:19 <ralonsoh> slaweq, no, not stop using neutron channel
14:54:45 <ralonsoh> but not deferring the change
14:55:05 <slaweq> ralonsoh: I was asking about if there is anyone who will simply say "I'm not going to use freenode so I will not be available on irc anymore, unless You will move to other server"
14:55:23 <mlavalle> I also say option 1
14:55:33 <slaweq> if there are people who consider that, I will personally vote for option 2, otherwise I'm also for option 1 :)
14:56:23 <mlavalle> we are not saying not move if we take option 1. we are saying let's find more
14:56:32 <mlavalle> facts
14:56:43 <mlavalle> and see how the situation evolves
14:57:01 <gmann> exactly
14:57:02 <bcafarel> I just hope end decision will be global to openstack (fragmentation--) I know devs/users on other opensource projets went that way (not going to use freenode either again), but I don't know for openstack and neutron specifically
14:57:10 <obondarev> I just don't want to move 1 times :)
14:57:18 <obondarev> 2 times *
14:57:23 <lajoskatona> +1
14:57:26 <amotoki> +1
14:57:45 <slaweq> ok, so to summarize, neutron team is for option 1, let's wait a bit more and see how it will goes
14:57:52 <manubk> +1 for option 1
14:57:57 <mlavalle> +1
14:58:07 <haleyb> +1 to avoid fragmentation, option 1 is fine assuming that
14:58:12 <slaweq> I will update etherpad right now :)
14:58:32 <slaweq> thx for all feedback there
14:58:40 <mlavalle> and yeah, if we move, all openstack should move in one step
14:58:51 <mlavalle> not fragmented
14:59:28 <slaweq> that's all what I had for today
14:59:50 <slaweq> and I think we can finish the meeting for today
15:00:01 <slaweq> thx a lot for attending and great discussion
15:00:04 <mlavalle> oh, we get 1 minute back \o/
15:00:10 <slaweq> have a great week :)
15:00:14 <slaweq> mlavalle: sure :D
15:00:16 <ralonsoh> bye
15:00:18 <mlavalle> o/
15:00:19 <slaweq> #endmeeting