14:00:09 <ralonsoh> #startmeeting networking 14:00:09 <opendevmeet> Meeting started Tue Jul 4 14:00:09 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:09 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:09 <opendevmeet> The meeting name has been set to 'networking' 14:00:15 <ralonsoh> hello all 14:00:29 <obondarev> hi 14:00:45 <elvira> hi o/ 14:01:09 <ralonsoh> rubasov, slaweq, lajoskatona? 14:01:12 <lajoskatona> o/ 14:01:19 <bcafarel> o/ 14:01:28 <rubasov> o/ 14:01:30 <slaweq> o/ 14:01:35 <slaweq> sorry for being late 14:01:38 <ralonsoh> np 14:01:51 <ralonsoh> ok, let's start (US folks are celebrating today) 14:02:01 <ralonsoh> #topic annoucements 14:02:08 <ralonsoh> #link https://releases.openstack.org/bobcat/schedule.html 14:02:22 <ralonsoh> and finally we are in Bobcat-2 14:02:30 <ralonsoh> #link https://releases.openstack.org/bobcat/schedule.html#b-2 14:02:43 <ralonsoh> And we have the corresponding "releases" patches 14:02:53 <ralonsoh> #link https://review.opendev.org/c/openstack/releases/+/887499 14:03:04 <ralonsoh> #link https://review.opendev.org/c/openstack/releases/+/887492 14:03:16 <ralonsoh> and today we have merged the requirements patch for n-lib 3.7.0 14:03:33 <lajoskatona> toooo much information :-) 14:03:43 <ralonsoh> yeah hehehe (I have more...) 14:04:00 <ralonsoh> related to these "releases" patches, there are other 2 that should have your attention 14:04:13 <ralonsoh> the first ovn-bgp-agent release 14:04:15 <ralonsoh> #link https://review.opendev.org/c/openstack/releases/+/887385 14:04:35 <lajoskatona> \o/ 14:04:36 <ralonsoh> and the EOL of n-odl in Ussuri (because the CI is broken) 14:04:38 <ralonsoh> #link https://review.opendev.org/c/openstack/releases/+/887152 14:04:57 <ralonsoh> so please, after this meeting check these ^^ patches and vote 14:04:59 <ralonsoh> thanks! 14:05:17 <ralonsoh> something else you want to add? 14:05:44 <ralonsoh> ok, let's go for the bugs 14:05:47 <ralonsoh> #topic bugs 14:06:01 <ralonsoh> last week report is from haleyb 14:06:03 <ralonsoh> #link https://lists.openstack.org/pipermail/openstack-discuss/2023-July/034314.html 14:06:20 <ralonsoh> first of all, thanks for your collaboration opening and solving bugs in Neutron 14:06:34 <ralonsoh> the report is full of them! but most of them already addressed 14:06:39 <ralonsoh> so, again, thank you all! 14:06:58 <ralonsoh> the only one that is not addressed is 14:07:00 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2025410 14:08:29 <ralonsoh> haleyb, "reproduced" this issue but actually what we find in the qroute namespace is the stale arp entry 14:08:48 <ralonsoh> and I think that's ok (??). Should we manually remove the arp entry? 14:10:02 <ralonsoh> ok, next week I'll ping haleyb about this one, to have more feedback 14:10:25 <slaweq> I'm not sure but I think we were adding manually some arp entries in dvr routers in the past 14:10:26 <ralonsoh> he investigated this one and he could maybe provide a resolution 14:10:33 <ralonsoh> let me check 14:11:39 <ralonsoh> I only see that in DVR routers 14:11:55 <obondarev> for FIPs, right? 14:12:25 <ralonsoh> not really, these are the fixed_ips 14:12:42 <slaweq> https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr.py#L46 14:12:52 <ralonsoh> ^^ exactly 14:13:06 <slaweq> it's like that even in master 14:13:30 <obondarev> ah, I see 14:13:41 <ralonsoh> what is the name of the dvr router namespace in the compute nodes? 14:13:44 <slaweq> but maybe it's not really called in master anymore 14:13:58 <slaweq> ralonsoh it's just qrouter-XXX 14:14:21 <ralonsoh> ok yes, snat is for networker node 14:14:28 <slaweq> yes 14:14:46 <ralonsoh> ok, I'll check with Brian and I'll try to reproduce it too locally 14:14:47 <slaweq> and for FIPs there is fip-<network_id> namespace also 14:14:50 <slaweq> on computes 14:15:52 <ralonsoh> anyway, we can continue the investigation offline 14:16:06 <ralonsoh> do you have any other bug to bring to this section? 14:16:37 <ralonsoh> this week amotoki is the deputy, next week will be mlavalle 14:16:40 <ralonsoh> ok? 14:17:10 <ralonsoh> I'll ping amotoki later today (or I'll send him a mail) 14:17:21 <ralonsoh> next section 14:17:24 <ralonsoh> #topic os-ken 14:17:42 <ralonsoh> I think you already know we are moving away from storyboard 14:18:01 <lajoskatona> good to hear 14:18:01 <ralonsoh> my question is about the content of https://storyboard.openstack.org/#!/page/about 14:18:34 <ralonsoh> and related to the second question: do we really need to open a launchpad site? 14:18:52 <ralonsoh> or can we handle the os-ken bugs as n-t-p or n-lib ones, in the same Neutron site 14:18:52 <ralonsoh> ? 14:18:58 <lajoskatona> isn't neutron is good to collect these bugs? 14:19:04 <lajoskatona> +1 14:19:05 <ralonsoh> I prefer this option ^ 14:19:12 <slaweq> we can have os-ken tag 14:19:15 <frickler> I'd say neutron is fine, just have a new tag 14:19:25 <lajoskatona> sounds good with the tag 14:19:25 <ralonsoh> exactly, same as [neutron-lib] 14:20:00 <ralonsoh> so I think it is decided: I'll send a mail just to make this public 14:20:04 <ralonsoh> thank you folks 14:20:18 <lajoskatona> thanks, good plan 14:20:29 <ralonsoh> along with that, I've realized that we have some (around 15 patches) pending from ryu to be backported... 14:20:31 <ralonsoh> my bad... 14:20:45 <ralonsoh> I'll start collecting them and opening the corresponding LP bugs 14:21:16 <frickler> ralonsoh: what was your question about the about page? I didn't get that 14:21:36 <ralonsoh> to open a https://bugs.launchpad.net/os-ken site 14:21:53 <ralonsoh> but I prefer to have os-ken bugs in the Neutron bug list 14:22:01 <frickler> ok, fine then 14:22:18 <ralonsoh> ok, so I'll send the mail after this meeting 14:22:40 <ralonsoh> next topic 14:22:46 <ralonsoh> #topic specs 14:23:14 <ralonsoh> all pending specs are merged now and we no longer accept new ones (although this is not strictly specified as in Nova project) 14:23:42 <ralonsoh> I need to talk to TC folks to know how to create this milestone, same as Nova 14:23:51 <ralonsoh> in any case, thank you all for your time reviewing 14:24:02 <ralonsoh> next topic 14:24:12 <ralonsoh> #topic community_goals 14:24:19 <ralonsoh> 1) Consistent and Secure Default RBAC 14:24:21 <ralonsoh> slaweq, please 14:24:33 <slaweq> sure 14:24:52 <slaweq> this week we merged https://review.opendev.org/c/openstack/neutron-lib/+/887191 14:25:11 <slaweq> which is needed to move on with service role patch in neutron 14:25:50 <slaweq> but I just today realized that it probably breaks some UT https://bugs.launchpad.net/neutron/+bug/2025753 14:26:07 <slaweq> so I need to investigate it first before I will propose new neutron-lib release 14:26:15 <slaweq> that's all from my side 14:26:25 <ralonsoh> (+1 for this periodic job) 14:26:37 <ralonsoh> thanks for the update! 14:26:58 <ralonsoh> btw, is there a bug/etherpad/link? 14:27:10 <slaweq> link for what? 14:27:11 <ralonsoh> for documentation purposes only 14:27:20 <ralonsoh> for the service role stuff 14:27:50 <ralonsoh> maybe you can open a LP bug to track that 14:28:13 <slaweq> sure 14:28:19 <ralonsoh> perfect! and thanks 14:28:32 <ralonsoh> the next section if 14:28:34 <ralonsoh> is 14:28:37 <ralonsoh> 2) Neutron client deprecation 14:28:48 <ralonsoh> lajoskatona, sdk patches are merged 14:28:48 <lajoskatona> The usual ehterpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation 14:29:33 <lajoskatona> yes one is still waiting for VPN: https://review.opendev.org/c/openstack/openstacksdk/+/886822 14:29:47 <ralonsoh> ah, I missed this one 14:29:50 <lajoskatona> I will ping sdk folks with it 14:29:59 <ralonsoh> is there a SDK patch in "releases"? 14:30:05 <lajoskatona> other than that I started to work on sfc things 14:30:16 <ralonsoh> just to know if they are going to release them soon 14:30:30 <lajoskatona> I realized that api-ref is missing from n-lib: https://review.opendev.org/c/openstack/neutron-lib/+/887193 14:31:01 <ralonsoh> 1600 lines! 14:31:04 <lajoskatona> and I pushed wip patches for sdk and neutronclient: https://review.opendev.org/c/openstack/openstacksdk/+/887387 & https://review.opendev.org/c/openstack/python-neutronclient/+/887388 14:31:31 <lajoskatona> api-ref is always a lot of chars :-) 14:31:54 <lajoskatona> it was hidden in sfc repo, so mostly just copy-paste 14:32:26 <ralonsoh> I'll add all these pending patches to the meeting agenda after this meeting 14:32:34 <lajoskatona> ack 14:32:43 <ralonsoh> lajoskatona, and again, thanks a lot for your work! 14:32:55 <lajoskatona> From next week I will be on 2 weeks PTO, so no progress is expected :-) 14:33:09 <ralonsoh> good to know! enjoy 14:33:30 <ralonsoh> and the last topic for today 14:33:36 <ralonsoh> #topic on_demand 14:33:42 <ralonsoh> elvira, has one topic 14:33:49 <elvira> yes :) 14:34:06 <elvira> Right now there are parameters for certain operations that are not useful depending on the driver. I think it would be sensible to convey to the users that such parameters are not available for the driver they have when they try to use it. 14:34:25 <elvira> for example: this arose with the network logging object 14:34:54 <elvira> when you create it, there is a --target parameter that is not useful with the ML2/OVN driver, but it is useful with ML2/OVS 14:35:31 <elvira> I think this might be the case for many other commands. Right now we just ignore parameters that are not expected. Should we take a more comprehensive approach somehow? 14:36:34 <ralonsoh> how is the "target" parameter used in ML2/OVS? jsut asking 14:36:42 <elvira> An approach I was suggested from our QE folks was to answer with an error through the API, explaining that the parameter is not supported 14:37:19 <elvira> ralonsoh: in ml2/OVS you can target only 1 port, but in OVN you always log per security group 14:38:01 <elvira> you cannot tighten the logging to just one port (well, maybe technically you could, by creating 1 security group only for that specific port) 14:38:26 <ralonsoh> do you have a list of parameters with/without use per mech driver? 14:38:27 <lajoskatona> this sounds like driver driven API :-) 14:39:00 <ralonsoh> ^ right and "we don't do this in Neutron"... 14:39:17 <elvira> lajoskatona: That is why I'm asking here, because maybe we could see if there is a way of doing this that is benefitial for the users of all drivers 14:39:41 <lajoskatona> good idea, thans for coming with this topic here 14:39:53 <ralonsoh> I think that will depend on the parameter. In this case where a parameter is useless for one mech driver, it could be documented 14:40:15 <slaweq> one thing I'm affraid of is that we can expose to the regular user details about cloud internals, like backend used 14:40:25 <slaweq> and I think we shouldn't do that for normal users 14:40:34 <ralonsoh> ^ another reason too 14:40:51 <slaweq> for admin only api this may be ok but not for regular user 14:41:16 <elvira> ralonsoh: Another solution could be stating it in the CLI if a parameter is only useful for 1 driver 14:41:30 <elvira> But I don't know how of a burden it is right now to change CLI messages 14:41:33 <ralonsoh> exactly, that could be defined in the CLI help 14:41:53 <ralonsoh> this is easy to be changed in the OSC repo 14:42:17 <elvira> Isn't this on the deprecated Neutron CLI anymore? 14:42:24 <ralonsoh> no no, not neutronclient 14:42:25 <rubasov> I also don't see a problem with some drivers returning a "Not Implemented" error 14:42:26 <ralonsoh> openstackclient 14:42:58 <elvira> rubasov: Oh, that would keep the API driver-agnostic 14:43:28 <ralonsoh> in this case that maybe (maybe) could be done by the logging manager, listing the loaded drivers 14:43:48 <rubasov> yeah in that case nobody needs to know what driver is configured in neutron, just that this won't work here... 14:43:57 <ralonsoh> elvira, do you have more parameters? or just this one? 14:44:21 <slaweq> for qos we have admin api to list available rules and parameters supported by loaded drivers 14:44:31 <elvira> ralonsoh: right now I only have this one, but talking with bcafarel he explained to me that this is the case for many parameters and the linuxbridge driver 14:44:37 <slaweq> maybe we can do something similar for logging api, but for admin only 14:45:09 <elvira> So that is mostly why I wanted to talk about it on a general perspective, just in case it was benefitial for more users 14:45:34 <elvira> Anyway, I can also create a launchpad to continue this discussion 14:45:37 <ralonsoh> elvira, I think we can't provide a general solution. That will depend on the parameter 14:45:43 <elvira> if this sounds like a legit problem 14:46:28 <ralonsoh> in this case you have several solution that could be applied in parallel: 1) the CLI help command, 2) the driver listing and 3) the logging manager rejecting the command knowing the loaded drivers (that are only OVS and OVN) 14:46:51 <ralonsoh> so please, open a LP bug to track this and the solutions implemented 14:47:11 <elvira> ralonsoh: ok! thanks a lot for the insights to everyone 14:47:17 <elvira> I will open it :) 14:47:20 <lajoskatona> +1 for the bug 14:48:00 <ralonsoh> and that's all I have for today folks, anything else? 14:48:11 <opendevreview> Slawek Kaplonski proposed openstack/neutron stable/2023.1: Don't allow deletion of the router ports without IP addresses https://review.opendev.org/c/openstack/neutron/+/887614 14:48:19 <ralonsoh> in about 10 mins we'll have the CI meeting in this channel 14:48:36 <opendevreview> Slawek Kaplonski proposed openstack/neutron stable/zed: Don't allow deletion of the router ports without IP addresses https://review.opendev.org/c/openstack/neutron/+/887615 14:48:38 <ralonsoh> thank you all! 14:48:41 <ralonsoh> #endmeeting