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