14:00:25 <ralonsoh> #startmeeting networking 14:00:25 <opendevmeet> Meeting started Tue May 23 14:00:25 2023 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:25 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:25 <opendevmeet> The meeting name has been set to 'networking' 14:00:28 <mlavalle> o/ 14:00:29 <lajoskatona> o/ 14:00:33 <ralonsoh> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 14:00:40 <han-guangyu> o/ 14:00:41 <isabek> Hi 14:00:44 <averdagu> o/ 14:00:49 <bcafarel> o/ 14:00:56 <slaweq> o/ 14:01:03 <sahid> o/ 14:01:11 <ges> o/ 14:01:45 <ralonsoh> ok, I think we can start now 14:01:46 <ykarel> o/ 14:01:58 <ralonsoh> #topic announcements 14:02:08 <ralonsoh> #link https://releases.openstack.org/bobcat/schedule.html 14:02:32 <ralonsoh> 3 weeks for the Vancouver summit 14:02:44 <ralonsoh> #link https://etherpad.opendev.org/p/neutron-vancouver-2023 14:02:55 <rubasov> late o/ 14:02:55 <ralonsoh> if you are attending, please add your topics in this etherpad 14:03:24 <ralonsoh> and as usual 14:03:26 <ralonsoh> #link https://openinfra.dev/live/#all-episodes 14:03:40 <ralonsoh> please check the list of video episodes the openinfra channel has 14:04:00 <ralonsoh> something else I'm missing? 14:04:24 <ralonsoh> ok, let's jump to the next topic 14:04:26 <ralonsoh> #topic bugs 14:04:38 <ralonsoh> last week report is from elvira 14:04:41 <ralonsoh> #link https://lists.openstack.org/pipermail/openstack-discuss/2023-May/033781.html 14:04:56 <ralonsoh> there are 3 bugs still not assigned/under triage 14:05:04 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2020001 14:05:08 <ralonsoh> Neutron Dynamic Routing : vip is not advertised via BGP 14:05:39 <ralonsoh> (to be honest, I didn't have time to check this one) 14:06:00 <ralonsoh> frickler, froyo can you check this one? 14:06:13 <elvira> I marked it as undecided because Jens Harbott was already discussing with the reported and marked it as incomplete 14:06:27 <froyo> ralonsoh: yeah, I will take a look 14:06:44 <ralonsoh> yes but Yusuf replied to this comment too 14:07:00 <elvira> Yes, I see it, thanks ralonsoh and froyo! 14:07:11 <ralonsoh> but apart from reading the reply, I didn't investigate it 14:07:36 <ralonsoh> froyo, thanks for your help, please comment on the LP if you have any proposal or conclusion 14:07:37 <ralonsoh> thanks! 14:07:58 <froyo> sure 14:07:59 <ralonsoh> next one 14:08:04 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2020060 14:08:09 <ralonsoh> Stateless Feature of Security Group Not Functioning in Case of other Port same compute use statefull 14:08:15 <ralonsoh> seems to be a corner case 14:08:45 <ralonsoh> when two rules have enabled and disabled the stateful flag 14:08:50 <slaweq> I have it on my todo list for this week 14:08:51 <slaweq> bu 14:08:56 <ralonsoh> and there are clashing iptables rules 14:09:09 <slaweq> but I will probably check it around Thursday or Friday 14:09:32 <ralonsoh> the point is that: is it possible to avoid this? or this should be prevented from the API? 14:09:44 <ralonsoh> because I don't see how can we prevent that in iptables 14:10:48 <slaweq> do You mean to avoid mixing stateless and stateful SGs on the same host? From the API PoV? 14:11:53 <ralonsoh> yes, if you have both type of rules in the same host, the iptables rules will overwrite the CT stsate 14:12:24 <slaweq> but doing such validation in the API may be extremely hard to do 14:12:25 <ralonsoh> well, not the same host but the same port 14:12:34 <slaweq> ahh, ok 14:12:36 <ralonsoh> yes... this is why I don't know how to solve this issue 14:12:38 <slaweq> that's easier 14:12:42 <ralonsoh> ahh ok ok 14:12:58 <ralonsoh> so if the port has "mixed" rules --> error 14:13:16 <ralonsoh> (btw, this seems to be an issue for LB, not other backends) 14:13:27 <lajoskatona> you mean when the port is created ? or when the sg is updated with the new rule? 14:13:33 <ralonsoh> both 14:13:39 <lajoskatona> ok 14:13:45 <slaweq> I will check it but that should be easy to do 14:13:48 <slaweq> or it even maybe should be like that already 14:13:58 <opendevreview> Fernando Royo proposed openstack/neutron-lib master: Add FIPAssociated exception https://review.opendev.org/c/openstack/neutron-lib/+/883901 14:13:58 <ralonsoh> yeah 14:14:14 <slaweq> https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_db.py#L709 14:14:14 <ralonsoh> slaweq, anyway, thanks again for assigning this bug to yourself 14:14:18 <slaweq> we have that validation 14:14:19 <ralonsoh> let me check 14:14:26 <ralonsoh> yeah right 14:14:36 <slaweq> maybe it's then just a bug that this validation is not executed in some case 14:14:44 <slaweq> I will check it 14:15:13 <ralonsoh> thanks! 14:15:23 <ralonsoh> last one 14:15:26 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2020168 14:15:31 <ralonsoh> [OVN][HWOL] traffic problems when sriov and non-sriov ports are bound on the same hypervisor 14:15:39 <ralonsoh> I see the submitter replied to my questions 14:15:50 <ralonsoh> so the problem here is not the OVN routing, because the router is external 14:16:09 <ralonsoh> it seems to be an easier (from the Neutron point of view) network configuration 14:16:34 <ralonsoh> I'll assign this one to myself but without a direct access to the env, it could be difficult to debug it 14:16:40 <ralonsoh> I'll do my best here 14:17:26 <ralonsoh> ok, this is what I have here 14:17:32 <ralonsoh> any other bug to be discussed? 14:18:18 <ralonsoh> this week ykarel is the deputy, next week will be mtomaska 14:18:24 <ykarel> ack 14:18:35 <mtomaska> ACK 14:18:35 <ralonsoh> thanks folks 14:18:37 <ralonsoh> let's move to the next topic 14:18:40 <ralonsoh> #topic specs 14:18:48 <ralonsoh> #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open 14:18:52 <ralonsoh> first one 14:18:59 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron-specs/+/882151 14:19:10 <ralonsoh> I see lajoskatona addressed last comments 14:19:20 <ralonsoh> I'll check it tomorrow morning then 14:19:30 <lajoskatona> yes and just on my way to adress the last ones 14:19:48 <ralonsoh> but there are no other reviews apart from Bence 14:19:58 <ralonsoh> please please, review the specs 14:20:03 <ralonsoh> this one is almost ready, IMO 14:20:24 <ralonsoh> lajoskatona, any comment in this one? 14:20:57 <lajoskatona> nothing, as I wrote I will update the last comments from rubasov, and push it today I hope 14:21:02 <ralonsoh> thanks 14:21:10 <ralonsoh> next one 14:21:14 <opendevreview> Merged openstack/neutron stable/train: [Train Only] Drop openstacksdk-functional job https://review.opendev.org/c/openstack/neutron/+/883890 14:21:17 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron-specs/+/882272 14:21:27 <ralonsoh> I changed the initial spec 14:21:34 <ralonsoh> now instead of a flag is a string 14:21:41 <ralonsoh> but the spirit of the spec is the same 14:21:58 <ralonsoh> there are very good reviews of missing points/errors I need to address 14:22:06 <ralonsoh> but I think this spec is quite easy 14:22:22 <ralonsoh> next one 14:22:30 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron-specs/+/883481 14:22:37 <ralonsoh> an update from slaweq 14:22:59 <ralonsoh> the spec was moved to 2023.2 and added some missing fields 14:23:16 <ralonsoh> I'll check it tomorrow morning but changes are trivial, IMO 14:23:39 <ralonsoh> and last one (nova-specs) 14:23:43 <ralonsoh> #link https://review.opendev.org/c/openstack/nova-specs/+/859290 14:23:52 <ralonsoh> this is related to Napatech LinkVirt SmartNICs 14:24:05 <ralonsoh> half of the code is merged already 14:24:18 <ralonsoh> but please, check this spec 14:24:29 <lajoskatona> under this topic: https://review.opendev.org/q/topic:bug%252F2013540 14:24:31 <ralonsoh> two projects are involved on this one 14:24:54 <ralonsoh> yes, there are two patches for neutron/n-lib 14:25:05 <ralonsoh> the n-lib one is merged and released 14:25:32 <ralonsoh> from the Neutron point of view, this could be trivial 14:25:44 <ralonsoh> but we need to be sure when adding new vif and vnic types 14:26:10 <lajoskatona> +1 14:26:32 <ralonsoh> ok, something else (apart from begging for reviewers?) 14:27:07 <ralonsoh> ok, let's move on 14:27:13 <ralonsoh> #topic community_goals 14:27:18 <ralonsoh> 1) sRBAC 14:27:25 <ralonsoh> slaweq, I think there are no more bugs open 14:27:27 <ralonsoh> right? 14:27:41 <slaweq> nope 14:27:47 <slaweq> at least for now :) 14:27:52 <ralonsoh> perfect! 14:28:00 <slaweq> I need to focus on service-2-service communication now 14:28:12 <slaweq> but I first want to finish this default SG rules 14:28:16 <ralonsoh> yeah, do you have a public etherpad/lp bug for this? 14:28:24 <slaweq> not yet 14:28:34 <ralonsoh> ok, let's finish first the other feature 14:28:43 <ralonsoh> thanks! 14:29:02 <ralonsoh> next one 14:29:08 <ralonsoh> #2) Neutron client deprecation 14:29:15 <ralonsoh> lajoskatona, something relevant this week? 14:29:27 <lajoskatona> The usual etherpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation 14:29:36 <lajoskatona> 2 things from last time, for fwaas 14:29:55 <lajoskatona> I pushed a follow-up for SDK: https://review.opendev.org/c/openstack/openstacksdk/+/883859 14:30:19 <lajoskatona> this is to add a computed field for fw rules object, and I update the neutronclient patch for fwaas: 14:30:27 <lajoskatona> https://review.opendev.org/c/openstack/python-neutronclient/+/880629 14:30:45 <lajoskatona> that's all for this topic from me 14:30:59 <ralonsoh> yeah, apart from the sdk patch, we have 3 pending patches 14:30:59 <ralonsoh> https://review.opendev.org/q/topic:bug/1999774+status:open 14:31:14 <ralonsoh> sorry, "including" the sdk patch 14:31:48 <ralonsoh> thanks for the update (I'll add them to my review list for tomorrow morning) 14:32:23 <ralonsoh> ok, let's move on then 14:32:26 <ralonsoh> #topic on_demand 14:32:34 <ralonsoh> I have one quick topic 14:32:58 <ralonsoh> and this is the update of the grenade job issue from ykarel (but we can move this one to the nex tmeeting) 14:33:05 <ralonsoh> slaweq, ^^ ok? 14:33:54 <ralonsoh> ok, let's comment this issue during the CI meeting, that is more appropriate 14:34:01 <ykarel> +1 14:34:04 <ralonsoh> remember the CI meeting is in 30 mins in this channel 14:34:10 <ralonsoh> this week in video 14:34:15 <ralonsoh> (if I'm not wrong) 14:34:26 <lajoskatona> ack 14:34:38 <ralonsoh> ok folks, anything else you want to discuss? 14:35:11 <ges> I have this change in need of more discussion https://review.opendev.org/c/openstack/neutron/+/883235 14:36:03 <ralonsoh> we can move this discussion to the patch, if you don't mind. I'll check your reply today 14:36:11 <ralonsoh> also you can ping me in this channel too 14:36:25 <ges> Sure, thanks! 14:36:31 <ralonsoh> something else? 14:37:01 <ralonsoh> ok folks, thank you for attending and see you in 25 mins in this channel in the CI meeting 14:37:05 <ralonsoh> #endmeeting