14:00:14 <lajoskatona> #startmeeting networking
14:00:14 <opendevmeet> Meeting started Tue Sep 28 14:00:14 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:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:14 <opendevmeet> The meeting name has been set to 'networking'
14:00:19 <ralonsoh> hello
14:00:31 <lajoskatona> Hi everybody!
14:00:32 <erlon> dalvarez: yes, so, I dont see ARP reponses if I dont'  ping the ip
14:00:40 <rubasov> o/
14:00:42 <liuyulong> o/
14:00:55 <amotoki> o/
14:00:56 <haleyb> o/
14:01:02 <slaweq> hi
14:01:03 <dalvarez> erlon: i think you may be missing this: https://github.com/ovn-org/ovn/commit/96959e56d634c8d888af9e3ee340602593c7e4fa
14:01:12 <dalvarez> (sorry for the noise)
14:01:13 <erlon> but the thing is, there are some switches that once a ip is dicover, they keep sending pings to refresh the cache
14:01:47 <lajoskatona> dalvarez: side effect of no dedicated meeting channel :-)
14:01:56 <lajoskatona> #topic Announcements
14:02:12 <lajoskatona> Xena cycle calendar https://releases.openstack.org/xena/schedule.html
14:02:24 <lajoskatona> This week is final RC week, see: http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025081.html
14:02:37 <erlon> dalvarez: hmmm, that makes sense, sice the version Im using is 20.03, but have that other gARP patch of yours backported
14:02:38 <bcafarel> o/
14:02:41 <njohnston> o/
14:03:10 <lajoskatona> Please check the priority patches to review things quickly if we have to push fixes quickly
14:03:38 <erlon> dalvarez: do you remembered if you backported this one too?
14:03:52 <lajoskatona> Don't know if You follow the current gate issue with apache urls: http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025101.html
14:04:14 <slaweq> lajoskatona: there is only one now: https://review.opendev.org/c/openstack/neutron/+/810975
14:04:23 <slaweq> and it seems to be blocked by the apache issue :/
14:04:39 <lajoskatona> slaweq: thanks
14:04:51 <lajoskatona> I think these are the fixes on different branches in devstack:
14:05:06 <lajoskatona> https://review.opendev.org/c/openstack/devstack/+/811399 & https://review.opendev.org/c/openstack/devstack/+/811389 & https://review.opendev.org/c/openstack/devstack/+/811303
14:05:12 <dalvarez> erlon: meeting going on, i don't want to interfere but not, the backport goes down only from master to v21.06.0 branch
14:05:45 <lajoskatona> slaweq: by the way, and these: https://review.opendev.org/q/Id73368576a948f78a043d7cf0be16661a65626a9 ?
14:06:18 <lajoskatona> we can discuss these on the bug section, but wanted to have a feedback if we have to have that in xena
14:06:24 <erlon> hmm, sorry guys, didn't know the meetings were hosted on the channel now
14:07:17 <slaweq> lajoskatona: true, that one is also important
14:07:59 <slaweq> lajoskatona: I just set review-priority +2 for the Xena patch
14:08:03 <lajoskatona> slaweq: ok, thanks
14:08:12 <slaweq> lajoskatona: thx for reminding about it :)
14:09:00 <lajoskatona> slaweq: if I understand well the xean patch is almost a backport/cherry-pick , so if possible would be good to merge the master one first
14:09:14 <lajoskatona> but we can discuss it later or in review
14:09:40 <slaweq> lajoskatona: ralonsoh will have details for sure, but it is like that
14:09:43 <ralonsoh> sure
14:09:59 <slaweq> I'm just worried if we will be able to get merged both master and xena so fast
14:10:25 <lajoskatona> slaweq: yeah, that's my concern too
14:10:58 <lajoskatona> ok, let's discuss it separately
14:11:26 <lajoskatona> Do you have anything to announce?
14:12:07 <lajoskatona> Ok let's move then
14:12:24 <lajoskatona> #topic Bugs
14:12:36 <lajoskatona> bcafarel was bug deputy last week: http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025082.html
14:12:54 <bcafarel> thanks I was looking for the link :)
14:13:30 <lajoskatona> bcfarel: :-) quick copy-paste
14:14:05 <lajoskatona> From the critical section we are waiting for https://review.opendev.org/c/openstack/neutron/+/810975 to be merged to xena, so we are good from that perspective
14:14:36 <lajoskatona> bcafarel: do you have any bug to discuss?
14:15:25 <bcafarel> lajoskatona: no all good, as you said critical are being backported, the rest has assignees (or even fixes)
14:16:20 <bcafarel> (though as mentioned we have a few pending xena backports and that placement issue blocking gates)
14:17:11 <lajoskatona> thanks bcafarel for the report and the open eyes :-)
14:17:29 <lajoskatona> This week is rubasov's week and next week is for ralonsoh.
14:17:33 <ralonsoh> ok
14:17:34 <lajoskatona> is that ok?
14:17:36 <rubasov> ok
14:18:03 <lajoskatona> ok, thanks
14:18:58 <lajoskatona> Ok next topic then:
14:19:03 <lajoskatona> #topic L3
14:19:52 <lajoskatona> liuyulong has some topics, butperhaps he has network issues
14:20:51 <opendevreview> Rodolfo Alonso proposed openstack/neutron stable/xena: Execute the quota reservation removal in an isolated DB txn  https://review.opendev.org/c/openstack/neutron/+/811124
14:21:17 <liuyulong> Hi
14:21:21 <liuyulong> Thanks
14:21:31 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/770540
14:21:34 <lajoskatona> liuyulong: welcome back online :-)
14:21:46 <liuyulong> I'd like to raise the topic "elastic snat".
14:22:52 <liuyulong> We have implemented this locally, but the spec is still in in-progress state upstream.
14:22:53 <lajoskatona> liuyulong: ack, please do that
14:23:58 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/770540/14/specs/xena/elastic_snat.rst@110
14:24:57 <slaweq> liuyulong: I will review it again
14:25:02 <liuyulong> About this input "internal_cidrs", slaweq suggested that we make it coupled with the address group.
14:26:13 <slaweq> yes, because we have already that resource which can represent it so why not use it here?
14:26:16 <liuyulong> When we make this feature a real production on our cloud.
14:27:09 <liuyulong> We have received complaints from the upper platform about the complexity of API calls copled with address group.
14:28:37 <liuyulong> Every the user needs to update the ElasticSnat, they need to show it. And list/find the address groups, update the related address groups.
14:29:33 <amotoki> liuyulong: is it described or replied in the spec? (I haven't read thru the spec though :p)
14:29:41 <liuyulong> Instead of a simple update API of ElasticSnat.
14:29:50 <slaweq> but address groups may give You some possibilities to e.g. create group which will be used in some SG and also in that SNAT if needed
14:30:00 <liuyulong> amotoki, yes, I replied those.
14:30:17 <slaweq> IMHO there are many different use cases and we should use what we already have in Neutron
14:30:22 <slaweq> if that is possible
14:30:47 <slaweq> anyway, I'm not going to block this only because of that, but I would like others opinion about it too :)
14:30:59 <spatel> Does neutron support providing two nic for bonding? (this is the case of SRIOV based design)
14:31:29 <ralonsoh> there is no support for this because that is part of the underlying infraestructure
14:32:00 <lajoskatona> spatel: Hi, we have team meeting now, we can discuss it during the on demand agenda
14:32:16 <spatel> sorry about that.
14:33:06 <liuyulong> Update is just one example. Creating API has same issue. And for the API input validation, users address group IDs needs elastic_snat plugin to read DB one time to get the CIDR list.
14:33:37 <liuyulong> While the real CIDRs will be used to verify if it is valid for this router/subnets/ports.
14:33:40 <lajoskatona> slaweq, liuyulong: I tend to be on the side to use already existing API-s,
14:34:33 <lajoskatona> slaweq, liuyulong: I will check the discussion in the review, to have deeper understanding of the problem here
14:34:44 <slaweq> lajoskatona++ thx a lot
14:35:51 <amotoki> I will check the spec too. Complaints in user side may be able to be addressed in CLI or tool side too (unless it leads to performance issues in the server side)
14:36:11 <slaweq> amotoki++ thx
14:36:52 <liuyulong_> sorry, lost the connection.
14:37:13 <liuyulong_> Next one is https://review.opendev.org/c/openstack/neutron-specs/+/802854
14:37:21 <liuyulong_> "Spec for distributed datapath for metadata"
14:37:45 <liuyulong_> It has the metadata data path in detail.  So call for reviewers.
14:38:03 <liuyulong_> It's time to say goodbye to metadata-agent.
14:39:11 <liuyulong_> So here I have a very good picture about Neutron in the future.
14:39:18 <lajoskatona> liuyulong_: I will/ or you can raise the priority, I think this week will be a little crowded with ongoing release, but I will check this one as well
14:40:06 <liuyulong_> Neutron has only ovs-agent and L3-agent. Then the pressure of MQ and DB may narrow down to make Neutron to adopt to a real large scale deployment.
14:40:07 <slaweq> I also added it to my todo list
14:40:39 <liuyulong_> And more about L3 is, if someday the openflow related L3 are accomplished. (https://review.opendev.org/q/topic:%22bug%252F1931953%22+(status:open%20OR%20status:merged))
14:41:38 <liuyulong_> With ovs-dpdk or smartNIC offload, the dataplane performance will get better as well.
14:42:43 <liuyulong_> So, go go go, let's make Neutron more and more powerful and efficient.
14:42:50 <liuyulong_> : )
14:43:12 <lajoskatona> liuyulong_: thanks, hope that performance will better with these options
14:43:20 <obondarev_> liuyulong_: sounds great, thanks! :)
14:43:53 <opendevreview> Eduardo Olivares proposed openstack/neutron stable/xena: Replace cirros 0.4.0 by 0.5.2 in ovn migration create-resources.sh.j2  https://review.opendev.org/c/openstack/neutron/+/811340
14:44:13 <opendevreview> Eduardo Olivares proposed openstack/neutron stable/wallaby: Replace cirros 0.4.0 by 0.5.2 in ovn migration create-resources.sh.j2  https://review.opendev.org/c/openstack/neutron/+/811341
14:44:18 <liuyulong_> lajoskatona, no more L3 topics from me now. : )
14:44:33 <opendevreview> Eduardo Olivares proposed openstack/neutron stable/victoria: Replace cirros 0.4.0 by 0.5.2 in ovn migration create-resources.sh.j2  https://review.opendev.org/c/openstack/neutron/+/811342
14:44:45 <lajoskatona> liuyulong_: One question: Do these options like flow based dvr need some extra care for migrating from old L3 or metadata?
14:44:51 <opendevreview> Eduardo Olivares proposed openstack/neutron stable/ussuri: Replace cirros 0.4.0 by 0.5.2 in ovn migration create-resources.sh.j2  https://review.opendev.org/c/openstack/neutron/+/811343
14:45:07 <lajoskatona> liuyulong_: but I will check and ask in the spec reviews
14:45:37 <lajoskatona> liuyulong_:  thanks for the specs higlight
14:45:51 <liuyulong_> Link down is inevitable. Because the troditional namespace and iptables rules should be removed.
14:46:03 <liuyulong_> And the flows should be added then.
14:46:42 <lajoskatona> Ok, thanks, do anybody has perhaps anything more to discuss regarding L3?
14:47:30 <lajoskatona> #topic On Demand Agenda
14:47:48 <liuyulong> We can ask the migration issues in the spec patch of gerrit. Actually, I have no details about it either.
14:48:13 <liuyulong> I have one topic.
14:48:31 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1753466
14:49:22 <liuyulong> Since some smartNIC vendor indicates that their card may not support some CT actions.
14:49:55 <liuyulong> So stateful security group will be needed for it.
14:50:23 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/804807
14:50:31 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/789974
14:50:38 <ralonsoh> but is this only related to stateless FW?
14:50:51 <liuyulong> These two patches are for OVN to support stateless security gourp and NAT.
14:51:16 <liuyulong> So, here I'd like to mention that for ovs-agent we will need to supoort it too.
14:51:41 <lajoskatona> This bug isfor ovs: https://bugs.launchpad.net/neutron/+bug/1885261
14:52:03 <liuyulong> ralonsoh, yes
14:52:11 <liuyulong> lajoskatona, yes, long time no response
14:52:14 <ralonsoh> the implementation is not trivial, as with iptables
14:52:41 <liuyulong> [4] https://opendev.org/x/networking-ovs-dpdk/src/branch/stable/rocky/networking_ovs_dpdk/agent/ovs_dpdk_firewall.py
14:52:49 <ralonsoh> I know this FW very well
14:52:55 <ralonsoh> I implemented it
14:52:57 <slaweq> https://review.opendev.org/c/openstack/neutron/+/804807 is for stateless FIPs, not SG
14:53:01 <liuyulong> ralonsoh, this is mentioned in the bug 1885261. And I noticed it was implemented by you.
14:53:22 <liuyulong> So it should be fine to move to neutron?
14:53:38 <slaweq> do You want to have something similar for ML2/OVS case? How exactly?
14:53:39 <ralonsoh> I don't think this is working at all as is right now
14:54:12 <liuyulong> ralonsoh, yes, I tested it. It's not working.
14:54:23 <ralonsoh> I tried, when I implemented it, to merge it in Neutron
14:54:28 <lajoskatona> networking_ovs_dpdk is mostly abandoned, am I right?
14:54:39 <ralonsoh> but the answer was no because we had the CT one
14:54:41 <ralonsoh> lajoskatona, yes
14:54:47 <liuyulong> But, mainly code is fine, I'm going to fix it.
14:54:49 <ralonsoh> it is not needed anymore
14:55:07 <ralonsoh> liuyulong, perfect. Now the question is if we can handle two FWs in Neutron code
14:55:18 <ralonsoh> (and maintenance and testing and etc.)
14:55:45 <liuyulong> SmartNIC offloading is general trend. IMO, we should.
14:55:53 <lajoskatona> For this we need dpdk?
14:55:55 <opendevreview> Eduardo Olivares proposed openstack/networking-ovn stable/train: Replace cirros 0.4.0 by 0.5.2 in ovn migration create-resources.sh.j2  https://review.opendev.org/c/openstack/networking-ovn/+/811430
14:56:03 <ralonsoh> lajoskatona, not anymore
14:56:13 <lajoskatona> ralonsoh: thanks
14:56:14 <ralonsoh> CT is now supported in dpdk
14:56:15 <liuyulong> stateless fw is not only for ovs-dpdk, but also for smartnic offload
14:57:06 <liuyulong> ralonsoh, it is still utilize the kernel CT tables?
14:57:18 <ralonsoh> no, CT is implemented locally
14:57:28 <liuyulong> ralonsoh, if so, the performance should not be good engough.
14:57:34 <ralonsoh> it is now
14:58:08 <ralonsoh> ok, I'm not against it
14:58:22 <ralonsoh> but we should mark it as a testing feature
14:58:33 <lajoskatona> Do You think that we have to continue this discussion on drivers meeting?
14:58:41 <ralonsoh> and code should be isolated, as the other FW
14:58:46 <ralonsoh> perfect
14:58:53 <ralonsoh> that's the place
14:58:53 <liuyulong> I will take a deep look at the CT in dpdk. and the support status of ovs-dpdk.
14:59:10 <lajoskatona> I will add then this to the Friday agenda, is that ok  liuyulong ?
14:59:22 <liuyulong> ralonsoh, it will be configurable, a new fw driver will be added.
14:59:24 <amotoki> lajoskatona: I think it is a good idea. even if we have no RFEs to discuss we can use the meeting time to discuss such improvements.
14:59:40 <lajoskatona> amotoki: +
14:59:45 <lajoskatona> +1
14:59:52 <liuyulong> I think it is approved. : )
15:00:00 <lajoskatona> ok, time is up, thanks for the discussion
15:00:06 <slaweq> thx
15:00:08 <liuyulong> OK, thanks
15:00:23 <lajoskatona> liuyulong: yeah but to have everybody interested in the "room" and discussu in details
15:00:56 <lajoskatona> Have a great week, see You later
15:00:58 <lajoskatona> #endmeeting