14:00:17 <lajoskatona> #startmeeting networking
14:00:17 <opendevmeet> Meeting started Tue Nov 23 14:00:17 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:17 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:17 <opendevmeet> The meeting name has been set to 'networking'
14:00:22 <mlavalle> o/
14:00:24 <lajoskatona> Hi everybody!
14:00:35 <slaweq> hi
14:00:37 <obondarev> hi
14:00:42 <rubasov> o/
14:01:04 <bcafarel> o/
14:02:02 <lajoskatona> ok, let's start
14:02:03 <ralonsoh> hi
14:02:11 <lajoskatona> #topic Announcements
14:03:06 <lajoskatona> First the meeting times: it seems that the best would be to keep all meetings untouched so keep the current time slots
14:03:22 <lajoskatona> Team meeting :Tuesday 1400UTC
14:03:35 <lajoskatona> CI meeting Tuesday 1500TC
14:03:47 <mlavalle> +1 Good for me
14:03:56 <lajoskatona> Drivers meeting Friday 1400UTC
14:04:17 <lajoskatona> good :-)
14:04:51 <lajoskatona> If you have any comments please answer to the mails I sent today.
14:06:03 <slaweq> so all stays like it was
14:06:05 <slaweq> :)
14:06:09 <slaweq> good for me
14:06:13 <lajoskatona> It would be good to have more people from "the east" India, central asia, east asia, but hard to find good timeslot
14:06:22 <bcafarel> no need to update my calendar, good for lazy me
14:06:40 <obondarev> :)
14:06:49 <lajoskatona> Nova as I know experienced with a special east asian meeting slot or more an "office-hour" but not much success
14:07:03 <lajoskatona> bcafarel: yeah true :-)
14:07:22 <slaweq> in neutron we had in the past 2 different time slots for the meetings which were biweekly
14:07:38 <liuyulong> Nothing changed, good to know, p.s. 1400 UTC is 10 p.m. in Beijing. Many times, I had already go to bed.
14:07:42 <slaweq> but we changed that as there was not a lot of people attending one of them
14:07:52 <lajoskatona> Yeah I remember, was that more visited?
14:08:13 <lajoskatona> liuyulong: Hi, I totally understand that
14:08:24 <slaweq> lajoskatona: I remember that on the meeting which was around midnight my time there was maybe 2 or 3 people
14:08:41 <slaweq> so I changed that finally to have it always on Tuesday
14:08:57 <lajoskatona> slaweq: ok
14:09:23 <lajoskatona> yeah that was too late for me, and if I had no special topic for it I just skipped as I remember :-)
14:10:01 <lajoskatona> ok, I think we can jump to the next point
14:10:14 <lajoskatona> Yoga cycle calendar https://releases.openstack.org/yoga/schedule.html
14:11:18 <lajoskatona> the Yoga-1 release patches are out (i.e.: https://review.opendev.org/c/openstack/releases/+/818428 or https://review.opendev.org/c/openstack/releases/+/818417 )
14:11:59 <liuyulong> Too many running OpenStack clouds need me to take care in daytime. So, I have to go bed earlier to recover. : )
14:12:44 <lajoskatona> Last week the ussuri branch was transitioned to em: https://review.opendev.org/c/openstack/releases/+/817605
14:13:17 <lajoskatona> and networking-midonet: transition pike, queens and rocky to eol
14:14:07 <lajoskatona> There was a mail for testing runtime: http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025881.html
14:14:39 <lajoskatona> TC decided to remove py36 from jobs and as py39 voting everywhere
14:15:08 <lajoskatona> as I saw we have no problem with py39, do you know something to focus on regarding py39 jobs?
14:15:28 <slaweq> I think it should be ok
14:15:50 <lajoskatona> slaweq: ok
14:16:19 <slaweq> according to https://grafana.opendev.org/d/BmiopeEMz/neutron-failure-rate? viewPanel=22&orgId=1&from=now-30d&to=now it seems that now it's following other ut jobs
14:16:36 <slaweq> but about 1-2 weeks ago it was failing much more often than e.g. py36 or 38
14:16:46 <slaweq> so we will need to keep an eye on it
14:16:51 <ralonsoh> (dut to timeouts, seems that py39 takes more time)
14:17:02 <slaweq> ralonsoh: can be
14:18:24 <lajoskatona> so grfana dashbourd should be updated perhaps to have py39 on it? I see only py38
14:19:48 <slaweq> lajoskatona: there is openstack-tox-py39 there
14:19:53 <slaweq> as non-voting job
14:20:07 <slaweq> so we will only need to update it to be "voting"
14:20:14 <slaweq> and add to the gate queue graph
14:20:16 <lajoskatona> slaweq: ok I see now, the board half loaded for me it seems for first....
14:21:11 <lajoskatona> ok, if no comments/questions for announcements, we can go to next topic
14:21:31 <lajoskatona> #topic Bugs
14:21:33 <bcafarel> yep py39 looks in line with other UT jobs in recent days
14:21:57 <lajoskatona> hongbin was bug deputy last week: http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025895.html
14:22:43 * frickler has been busy filing bugs with OVN+DNS
14:22:49 <lajoskatona> I checked and the found few without owner:
14:22:57 <lajoskatona> #link https://bugs.launchpad.net/neutron/+bug/1951010  Restarting Neutron floods Nova with segment aggregates calls
14:23:22 <lajoskatona> frickler: thanks for filing those
14:24:45 <lajoskatona> I think this is one of those: #link https://bugs.launchpad.net/neutron/+bug/1951074  [OVN] default setting leak nameserver config from the host to instances
14:25:34 <lajoskatona> Do you have perhaps comments or notes for the bug report?
14:26:10 <frickler> I think it's all written there, I open to any questions as always
14:26:46 <lajoskatona> ok
14:27:15 <frickler> this search has all others, too
14:27:15 <frickler> https://bugs.launchpad.net/neutron/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&fi
14:27:21 <frickler> eld.subscriber=&field.structural_subscriber=&field.tag=ovn+dns&field.tags_combinator=ALL&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_bluepr
14:27:23 <mlavalle> lajoskatona: I can take a look at  "Restarting Neutron floods Nova with segment aggregates calls"
14:27:27 <frickler> ints=on&search=Search
14:27:35 <lajoskatona> mlavalle thanks
14:27:46 <frickler> oops, that's a long lp link. essentially look for tags "ovn"+"dns"
14:29:34 <frickler> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ovn+dns&field.tags_combinator=ALL
14:31:04 <lajoskatona> frickler: thanks, thats much more friendly :-)
14:31:18 <frickler> I'm really thinking having a flag to disable all this DNS spoofing and just using dhcp-agent for that would be great
14:32:21 <lajoskatona> For this week haleyb changed with ralonsoh to be deputy I think, at least I have seen something on irc
14:32:27 <ralonsoh> yes
14:32:44 <haleyb> yes, i'm out after today, thanks ralonsoh
14:32:49 <lajoskatona> frickler: I think that was mentioned earlier as workaround, so perhaps it should be documented somewhere
14:33:20 <lajoskatona> haleyb, ralonsoh: thanks I will update the table on the meetings wiki page
14:33:35 <frickler> lajoskatona: I'm currently testing running with dhcp-agent, but I haven't found out how to disable the OVN spoofing part
14:33:39 <lajoskatona> Next week I will be the deputy
14:35:14 <lajoskatona> ok I think if there's no more comments for bugs we can jump
14:35:19 <lajoskatona> #topic L3 subteam
14:35:24 <lajoskatona> #link https://wiki.openstack.org/wiki/Network/Meetings#L3_subteam
14:36:02 <lajoskatona> liuyulong: if you are still with us, do you have anything related to L3?
14:36:36 <liuyulong> one topic
14:36:37 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/770540
14:36:56 <liuyulong> What do you guys think about this spec of "elastic snat"?
14:37:28 <liuyulong> Should we move forward?
14:37:57 <lajoskatona> liuyulong: from my side the idea is really good and as I see the review moved to fix small things in the spec
14:38:11 <lajoskatona> I plan to go back and check the last ps
14:39:04 <liuyulong> It has been 9 month for this spec. Pretty slow in progress. : )
14:40:36 <lajoskatona> that's true
14:40:46 <slaweq> I will review it again
14:41:35 <liuyulong> Good, thank you guys.
14:42:40 <liuyulong> New features are always weclomed for cloud users. : ) This is also one of the sign of the activity of the community.
14:42:57 <mlavalle> I will review it also
14:43:42 <lajoskatona> thanks you very much for the update and headsup
14:44:08 <liuyulong> Something in short, port forwarding is the DNAT work, while this is SNAT.
14:44:38 <liuyulong> The two features have some similarities.
14:46:15 <liuyulong> OK, no more from me, please move on.
14:46:25 <lajoskatona> liuyulong: thanks
14:46:31 <lajoskatona> #topic ryu and os-ken
14:46:48 <ralonsoh> No updates in Ryu repo, still following the open bugs in this project.
14:46:48 <lajoskatona> there was no new change so we have nothing to do with os-ken
14:47:05 <lajoskatona> ralonsoh: thanks for following it
14:47:16 <lajoskatona> #topic On Demand Agenda
14:47:42 <ralonsoh> I have one
14:47:47 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/818399
14:47:55 <ralonsoh> I don't want to hijack this meeting
14:48:02 <ralonsoh> so I would like your comments in the review
14:48:11 <ralonsoh> those are the current options
14:48:12 <ralonsoh> 1) add a config knob (config driven API)
14:48:12 <ralonsoh> 2) use the upgrade check to emit a warning --> admin will need to change needed policies
14:48:12 <ralonsoh> 3) something else
14:48:55 * mlavalle added the patch to reviews pile
14:49:37 <slaweq> I already commented there and I'm for option 2 personally
14:50:13 <liuyulong> I guess you had read my last comment, from my actual cloud operation experience, it's better to let the cloud admins know things explicitly.
14:50:32 <slaweq> liuyulong: not yet
14:50:50 <opendevreview> mitya-eremeev-2 proposed openstack/neutron-tempest-plugin master: Set SG quota for specific project.  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/818933
14:50:58 <slaweq> but ralonsoh's option 2 gives such possibility, only not with config knob
14:51:06 <ralonsoh> they'll have this option when executing the upgrade check
14:51:23 <slaweq> admin can configure qos policy for ports from external network and then remove policy from the network itself
14:51:27 <liuyulong> alright, maybe we can continue the disscussion in the gerrit.
14:51:38 <ralonsoh> they'll have the information about (1) the external networks affected, (2) the FIPs and (3) the fixed ports in those networks
14:51:41 <ralonsoh> sure
14:51:49 <slaweq> thus nothing will really change and behaviour will be finally consistent with what is now for ports
14:52:13 <slaweq> I don't think that config option for that will help
14:52:47 <slaweq> this would be config driven api behaviour which IMO we shouldn't do
14:52:52 <lajoskatona> It is open for me as well , I will check the discussion under the review
14:53:01 <ralonsoh> thank you all
14:53:10 <slaweq> and if we will keep it by default as it was until now, nobody will notice that really
14:53:23 <slaweq> so everyone will still probably use it in old way
14:53:35 <mlavalle> good point
14:55:17 <liuyulong> maybe a add floating_qos_polidy_id to external network for the floating IPs to inherit, to save the tons of API for existing ports.
14:56:13 <slaweq> IMO that will not be good ux to have yet another qos policy parameter to set
14:56:13 <ralonsoh> that will fragment the API unnecessarily
14:56:30 <liuyulong> Then you mixed L2 qos to L3 IPs.
14:56:33 <slaweq> I think we should keep that API as consistent as possible
14:56:42 <ralonsoh> lajoskatona, as is new
14:56:47 <ralonsoh> as  is now*
14:56:51 <slaweq> in fact I think that this is kind of bug that it now works differently for FIPS only
14:58:09 <lajoskatona> yeah I think the good way to have similar behaviour for ports networks and fips, gw port etc...
14:59:21 <lajoskatona> ok, time is up, so I think we have to move this discussion back to gerrit :-)
14:59:23 <mlavalle> I have a personal announcement to make. I am leaving my position with Yahoo, to join bcafarel's team at Red Hat, starting this coming Monday. From the community Neutron project point of view, it means I'll continue working with y'all
14:59:33 <ralonsoh> welcome!
14:59:41 <bcafarel> yay :)
14:59:43 <liuyulong> floating_ip_qos_policy_id to external network can solve the problems with varity cloud settings.
14:59:47 <lajoskatona> mlavalle: good luck:-)
15:00:00 <lajoskatona> mlavalle: you move to France? :P
15:00:12 <liuyulong> congras!
15:00:21 <lajoskatona> #endmeeting