21:00:09 <mlavalle> #startmeeting networking
21:00:11 <openstack> Meeting started Mon Aug  5 21:00:09 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:14 <openstack> The meeting name has been set to 'networking'
21:00:19 <slaweq> hi
21:01:29 <haleyb> hi
21:01:47 <mlavalle> slow Monday?
21:01:49 <tidwellr> hi
21:02:35 <mlavalle> ok, let's get going
21:03:02 <mlavalle> #topic Announcements
21:03:37 <mlavalle> The next milestone is Train-3 on the week of September 9th
21:03:48 <mlavalle> so that's a liuttle bit more than a month
21:03:52 <mlavalle> from today
21:04:28 <mlavalle> Yesterday I nominated ralonsoh to join the Neutron core team: http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008225.html
21:04:47 <mlavalle> Most of you have provided positive feedback
21:05:12 <mlavalle> the nomination will be open all this week
21:06:14 <mlavalle> This week is the last one to enter your name in the Shanghai PTG planning etherpad, if you are planning to attend: https://etherpad.openstack.org/p/Shanghai-Neutron-Planning
21:06:50 <mlavalle> by the end of the week I will use the number of people registered to estimate how many people will attend out PTG
21:07:05 <mlavalle> any other announcements?
21:07:09 <slaweq> not too many so far on the list :/
21:08:36 <mlavalle> ok, let's move on
21:09:09 <mlavalle> #topic Blueprints
21:09:29 <mlavalle> These are the blueprints that we are tracking for T-3 https://etherpad.openstack.org/p/Shanghai-Neutron-Planning
21:09:34 <mlavalle> #undo
21:09:35 <openstack> Removing item from minutes: #topic Blueprints
21:09:46 <mlavalle> #topic Blueprints
21:10:19 <mlavalle> These are the blueprints we are tracking for T-3: https://launchpad.net/neutron/+milestone/train-3
21:10:40 <mlavalle> any updates?
21:11:48 <slaweq> this one https://blueprints.launchpad.net/neutron/+spec/subnets-different-pools-same-net looks for me like done, but maybe tidwellr has something more related to it which isn't linked there
21:11:59 <tidwellr> that one is done
21:12:24 <slaweq> thx tidwellr for confirmation :)
21:12:35 <mlavalle> ok, updated in Launchpad
21:12:48 <mlavalle> thanks tidwellr for this implementation
21:13:41 <tidwellr> np
21:14:08 <mlavalle> ok, let's move on
21:14:29 <mlavalle> #topic Community Goals
21:14:57 <mlavalle> any updates on community goals?
21:16:30 <mlavalle> ok, let's move on then
21:16:34 <slaweq> nothing new from me
21:16:59 <mlavalle> #topic Bugs
21:17:23 <mlavalle> Our deputy this week was haleyb
21:17:29 <mlavalle> and here's his report http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008258.html
21:18:07 <haleyb> there were a few in the DVR/L3 space which we can handle in that meeting
21:18:25 <mlavalle> ok
21:18:42 <haleyb> there were a couple others that needed owners, let me link
21:18:50 <haleyb> https://bugs.launchpad.net/neutron/+bug/1838431
21:18:51 <openstack> Launchpad bug 1838431 in neutron "[scale issue] ovs-agent port processing time increases linearly and eventually timeouts" [Medium,Confirmed]
21:19:54 <haleyb> liu had filed it, perhaps he can pick up
21:20:11 <mlavalle> if he doesn't< i will take it
21:20:22 <haleyb> ack
21:20:28 <mlavalle> kind of matches what we are doing in the performance sub-team
21:20:37 <mlavalle> I already left him a question in the bug
21:20:47 <slaweq> I just wrote a comment there too
21:21:08 <haleyb> https://bugs.launchpad.net/neutron/+bug/1838431 was the second one
21:21:08 <openstack> Launchpad bug 1838431 in neutron "[scale issue] ovs-agent port processing time increases linearly and eventually timeouts" [Medium,Confirmed]
21:21:14 <slaweq> it looks for me like "well known" problem with remote_security_group_id in SG
21:22:04 <haleyb> i could not reproduce one of the issues in ^^, and have asked what release it is.  there might be a missing notification, or some missing information when a port delete happens and a floating ip is associated
21:22:25 <slaweq> haleyb: You pasted same link twice
21:22:33 <haleyb> sigh
21:22:42 <haleyb> https://bugs.launchpad.net/neutron/+bug/1838403
21:22:43 <openstack> Launchpad bug 1838403 in neutron "Asymmetric floating IP notifications" [Medium,New]
21:22:49 <haleyb> that's better
21:23:17 <slaweq> thx :)
21:24:32 <haleyb> i can pick-up based on his response, have not confirmed the notification message on master
21:24:44 <mlavalle> thanks haleyb
21:25:14 <haleyb> and one more that slaweq filed
21:25:16 <haleyb> https://bugs.launchpad.net/neutron/+bug/1838760
21:25:17 <openstack> Launchpad bug 1838760 in neutron "Security groups don't work for trunk ports with iptables_hybrid fw driver" [High,Confirmed]
21:25:49 <tidwellr> hmm
21:26:06 <tidwellr> is it not documented that configuration doesn't work?
21:26:19 <slaweq> tidwellr: I don't think so
21:26:48 <tidwellr> I helped early on with some of that implementation, and we were definitely aware that the iptables_hybrid driver would not work
21:27:33 <mlavalle> a gap in the docs then?
21:27:35 <slaweq> tidwellr: and there is even test https://github.com/openstack/neutron-tempest-plugin/blob/master/neutron_tempest_plugin/scenario/test_trunk.py#L275 which is checking if such connectivity is in fact blocked
21:28:46 <slaweq> tidwellr: mlavalle so maybe I just didn't look for such info in docs because I assumed that if something is in tests, it should works
21:28:56 <tidwellr> I think this may be a long-standing gap in docs, we initially only supported the OVS firewall driver
21:29:20 <haleyb> is it this sentence? "Security rules via iptables
21:29:20 <haleyb> rules is obviously not supported, and never will be."
21:29:48 <haleyb> contributor/internals/openvswitch_agent.rst
21:29:57 <slaweq> haleyb: ha, so it's just matter of test bug than :)
21:30:08 <haleyb> that seems more the spec/implementation though
21:30:30 <tidwellr> how many users are going to read that? :)
21:31:01 <mlavalle> so the bug is really a doc gap
21:31:08 <haleyb> someone would have to confirm that wasn't just a case of my finding a good sentence with 'iptables' in it :)
21:31:08 <slaweq> mlavalle: and test bug
21:31:56 <tidwellr> haleyb: no, your right. That is in line with what I recall working on the initial implementation of trunk ports
21:32:02 <mlavalle> but the test should be there for the ovs fw driver, right?
21:32:42 <slaweq> mlavalle: this is tempest test and it can be run on deployment with any driver configured
21:33:04 <slaweq> so we should probably skip at least this part if there is not supported fw driver used on L2 agents
21:33:06 <tidwellr> mlavalle: trunk tests that check connectivity should be run with the OVS firewall driver
21:33:31 <mlavalle> I think we are all saying the same thing
21:33:50 <haleyb> admin/config-trunking.rst maybe needs the update then, it doesn't mention iptables, and is vague with "If the native OVS
21:33:50 <haleyb> firewall driver is to be used, we recommend that the MAC address of the parent
21:33:50 <haleyb> port be re-used on all subports."
21:34:57 <tidwellr> it would be nice if it were a little more "in your face" that this is an unsupported configuration.....
21:35:04 <slaweq> in this document there is even "Limitations" section https://docs.openstack.org/neutron/latest/admin/config-trunking.html#limitations-and-issues
21:35:12 <slaweq> so IMO it should be mentioned there
21:35:16 <tidwellr> ie fail the port binding or something
21:36:51 <slaweq> tidwellr: so are You saying that there should be an binding error when trying to bind trunk subport with configured SG when agent is using iptables_hybrid fw driver?
21:37:45 <tidwellr> slaweq: something along those lines, just thinking out loud about ways to really make it obvious this isn't supported
21:38:10 <slaweq> tidwellr: ok, understood
21:38:18 <slaweq> so IMO plan for this one would be:
21:38:43 <slaweq> 1. update docs to write this info in more visible place(s) also,
21:39:06 <slaweq> 2. fix tempest test to not run this part (or this test) on unsupported configuration,
21:39:29 <slaweq> 3. Try to do some more "in Your face" change as tidwellr proposed
21:39:34 <slaweq> do You agree?
21:39:38 <mlavalle> yes
21:39:41 <tidwellr> +1
21:40:02 <slaweq> thx, I will update bug with this plan and will take care of it
21:40:11 <mlavalle> cool
21:40:47 <mlavalle> The bugs deputy this week is amotoki
21:40:47 <slaweq> and I will also reduce importance of this bug as it's not high anymore IMO
21:41:06 <mlavalle> and next week it will be tidwellr's turn
21:41:25 <mlavalle> anything else on bugs?
21:41:31 <haleyb> not from me
21:41:43 <mlavalle> moving on
21:41:55 <mlavalle> #topic neutron-lib
21:42:07 <mlavalle> I think boden is off this week
21:42:24 <mlavalle> he is moving his family to Idaho, IIRC
21:43:03 <mlavalle> anything to say about neutron-lib?
21:43:38 <slaweq> there is one topic proposed by bcafarel
21:43:43 <mlavalle> I know
21:43:56 <slaweq> it's related to neutron-lib so I'm just saying :)
21:44:05 <mlavalle> let's move to open agenda
21:44:13 <mlavalle> #topic On-demand agenda
21:45:18 <mlavalle> so bcafarel asked whether we should do neutron-lib backports?
21:46:06 <mlavalle> I haven't seen a strong need to do it, but in specifc cases, like the one mentioned in the topic, I don't see why not
21:46:20 <mlavalle> what do others think?
21:46:23 <slaweq> I'm now looking at neutron-lib tags
21:46:33 <slaweq> and it looks that we did something like that in the past
21:46:45 <slaweq> we have 1.9.0 1.9.1 and 1.9.2
21:47:01 <slaweq> it is in Pike deliverables directory in releases repo
21:47:18 <slaweq> so IMO it shouldn't be any problem to do that
21:47:37 <mlavalle> yeah, that's what I think
21:48:02 <mlavalle> maybe we don't need to do it regularly, but when it is needed, let's do it
21:48:09 <slaweq> +!
21:48:11 <slaweq> +1
21:48:22 <tidwellr> +1
21:48:50 <slaweq> but we should be very careful with what we are backporting
21:49:35 <mlavalle> we should always be careful backporting...
21:49:46 <slaweq> I don't know even what CI jobs will be run for stable branches in neutron-lib
21:51:18 <slaweq> ok, it looks that we have at least tempest-full run on such patches: https://review.opendev.org/#/c/672165/ :)
21:51:27 <slaweq> and tempest-full-py3
21:51:32 <slaweq> so it's not bad :)
21:52:23 <mlavalle> still, let's keep it limited
21:52:36 <slaweq> I agree
21:53:08 <mlavalle> ok
21:53:16 <mlavalle> anything else to discuss today?
21:54:04 <slaweq> just one short heads-up
21:54:12 <slaweq> patch https://review.opendev.org/#/c/666409/ was merged today
21:54:34 <slaweq> so we removed "gateway_external_network_id" config option from neutron
21:55:09 <slaweq> I hope it will not break anything as haleyb expects :P but if You will find anything which may be related, just be aware of this patch :)
21:55:37 <mlavalle> good heads up
21:55:42 <mlavalle> thanks!
21:56:12 <mlavalle> anything else?
21:56:47 <slaweq> not from me
21:56:51 <mlavalle> ok, have a great week!
21:56:56 <mlavalle> thanks for attending
21:57:08 <mlavalle> #endmeeting