14:00:52 <ralonsoh> #startmeeting networking 14:00:52 <opendevmeet> Meeting started Tue Jan 2 14:00:52 2024 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:52 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:53 <opendevmeet> The meeting name has been set to 'networking' 14:00:55 <mlavalle> \o 14:00:56 <ralonsoh> hello all 14:01:05 <ralonsoh> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 14:01:10 <slaweq> Hi and HNY! 14:01:14 <ralonsoh> HNY! 14:01:26 <bcafarel> o/ and HNY all! 14:01:55 <ykarel> o/ HNY all !! 14:02:14 <elvira> o/ hny 14:02:14 <ralonsoh> this is going to be a short meeting, we'll review the calenda, bugs and on demand topics 14:02:24 <ralonsoh> next week haleyb will lead the meeting again 14:02:25 <slaweq> ++ 14:02:29 <ralonsoh> so let's start 14:02:34 <ralonsoh> #topic announcements 14:02:40 <ralonsoh> #link https://releases.openstack.org/caracal/schedule.html 14:02:55 <ralonsoh> most important thing: caracal milestone 2 14:03:03 <ralonsoh> #link https://releases.openstack.org/caracal/schedule.html#c-2 14:03:22 <ralonsoh> most relevant features should be approved and under review right now 14:03:37 <ralonsoh> as commented 2 weeks ago, some projects have a spec freeze now 14:03:44 <ralonsoh> we don't but we should not delay that 14:04:01 <ralonsoh> I'm guilty of not spending time last weeks on spec reviewal 14:04:10 <ralonsoh> but I'll ping you in Friday for that 14:04:22 <bcafarel> that time of year it is quite allowed 14:04:48 <ralonsoh> and last topic in this section is the Ussuri EOL patch 14:04:51 <ralonsoh> #link https://review.opendev.org/c/openstack/releases/+/903294 14:04:57 <ralonsoh> as commented (in the patch) 14:05:03 <ralonsoh> there are some open reviews 14:05:17 <ralonsoh> but I'm against merging them without the proper testing 14:05:24 <ralonsoh> (backports have removed the FT) 14:05:34 <ralonsoh> because are not working, so... no 14:05:54 <ralonsoh> so please comment on the open patches or in the releases one 14:06:12 <ralonsoh> something else? 14:06:54 <ralonsoh> ok, let's move on 14:06:57 <mlavalle> not from me 14:07:02 <ralonsoh> #topic bugs 14:07:12 <ralonsoh> we have (should have) 2 reports 14:07:24 <ralonsoh> from bcafarel: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/N7UNL4EI3ZJELP5FMLVCFAONUWTLVD3J/ 14:07:30 <bcafarel> quite a long report :) 14:07:34 <ralonsoh> heheheh 14:07:39 <ralonsoh> the other one is missing 14:07:48 <ralonsoh> but I collected the pending LP bugs 14:07:54 <ralonsoh> so we have 3 to discuss today 14:08:01 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2047101 14:08:05 <ralonsoh> The test case for 'rbac_policy_quota' execution reports an error. 14:08:18 <ralonsoh> if I'm not wrong, there is a opne review for this one 14:08:21 <ralonsoh> one sec... 14:08:35 <ralonsoh> yes 14:08:37 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904106 14:08:52 <ralonsoh> so I'll update the LP bug and assign it to liwejian 14:09:11 <ralonsoh> next one 14:09:14 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2047092 14:09:18 <ralonsoh> "We need a way to distinguish physical_network" 14:09:34 <ralonsoh> to be honest, I'm not sure aboyt what the bug is requesting 14:09:52 <ralonsoh> I commented in c#1 with other options (policies, RBACs) 14:10:06 <ralonsoh> but I have no idea what AZ means in this context 14:10:11 <ralonsoh> any idea? 14:10:50 <frickler> just guessing maybe they want to use tags instead. but your question for feedback will hopefully help 14:11:40 <ralonsoh> but tags are available for members, not only admins 14:12:06 <ralonsoh> maybe is asking for a way of grouping the physnets 14:12:22 <ralonsoh> in any case, more feedback will be needed for this bug/feature 14:12:29 <frickler> it all depends on the actual use case, which is missing, ack 14:13:08 <ralonsoh> ok, let's wait for more information from the reported then 14:13:27 <ralonsoh> last bug is from previous meetings 14:13:30 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2036423 14:13:35 <ralonsoh> "subnet's gateway ip can be unset while attached to router" 14:13:37 <ralonsoh> i 14:13:43 <ralonsoh> it is expired but still relevant 14:14:27 <ralonsoh> reviewing the code we don't handle correctly the subnet GW IP update 14:14:40 <ralonsoh> in the L3 agent or, as reported in the bug, in the OVS agent 14:15:07 <ralonsoh> so, IMO, if we are not handling this event, we should prevent that action (if the subnet is attached to a router) 14:15:15 <ralonsoh> ^^ do you agree? 14:16:04 <ykarel> +1 14:17:01 <ralonsoh> ok, I'll take this one then. Because that implies an API change, I don't think we'll be able to backport it. And, of course, we need to document that change. I'll push a patch soon. 14:17:03 <slaweq> ++ 14:17:26 <mtomaska> +1 as well. just finished reading 14:17:40 <slaweq> And probably some new shim API extension may be needed then 14:17:54 <ralonsoh> yes, exactly 14:18:07 <ralonsoh> thanks folks 14:18:13 <ralonsoh> that's all I have in this topic 14:18:20 <ralonsoh> any other pending bug? 14:18:52 <ralonsoh> and as commented, last section today 14:18:59 <ralonsoh> #topic on_demand 14:19:07 <ralonsoh> ^^ anything you want to add? 14:19:12 <mtomaska> yes I have a quick one 14:19:14 <ralonsoh> sure 14:20:12 <mtomaska> this patch. https://review.opendev.org/c/openstack/neutron/+/903572/9 I am adding a new RPC method which already exists in RPC interfaces. One way to solve it would be to start using oslo.messaging nemaspaces. Any concern if I start doing that? 14:20:34 <mtomaska> we currently set all RPC namespaces to None https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/constants.py#L566-L581 14:20:41 <ralonsoh> but we are already using it 14:20:42 <ralonsoh> namespace=constants.RPC_NAMESPACE_DHCP_PLUGIN 14:20:45 <ralonsoh> right? 14:21:08 <mtomaska> No we are not. I did that in my patch just to see if it will work. Notice the FIXME I left 14:21:34 <ralonsoh> no no, I mean from the base code 14:21:38 <ralonsoh> version='1.0') 14:21:41 <ralonsoh> sorry 14:21:51 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/903572/9/neutron/agent/dhcp/agent.py#b869 14:22:41 <mtomaska> yeah and that is None if I am reading that correctly https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/constants.py#L571 14:23:14 <slaweq> yes, all those are set to None currently 14:23:17 <ralonsoh> ok, I'm stupid! sorry 14:23:26 <slaweq> haha 14:23:34 <mtomaska> so essentially we have one namespace None :) 14:23:56 <ralonsoh> what method is clashing with "get_ports"? 14:23:56 <slaweq> IMHO You can propose to change that and we can try to start using them 14:24:01 <mtomaska> So I am wondering if it would be ok to start using namespaces after all these years of just using None 14:24:51 <mtomaska> metadata agent get_ports is clashing https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/metadata/agent.py#L70 14:24:54 <slaweq> TODO comment in that neutron-lib contants file is very old :) 14:25:27 <ralonsoh> right, I see 14:25:51 <ralonsoh> so for now I would (1) use get_dhcp_ports and (2) enable the namespaces 14:25:52 <mtomaska> other way to "fix it" would be to not use the same method_name 14:26:05 <ralonsoh> (2) is something that could introduce some errors 14:26:16 <ralonsoh> and could be a potential issue during upgrades 14:26:26 <mtomaska> hmm I would be for one option or the other but not both 14:26:29 <ralonsoh> agents with None and server with a string 14:26:53 <slaweq> right, how it will work with upgrade if we will change namespaces? 14:26:55 <ralonsoh> enabling the namespace names could be potentially problematic 14:27:16 <ralonsoh> when the server is upgraded, the non-updated clients will fail 14:27:18 <ralonsoh> all of them 14:27:37 <ralonsoh> but should be tested 14:27:46 <slaweq> ralonsoh: this IMO means that we can't do it really 14:28:27 <ralonsoh> because the migration alternative (if that really breaks the upgade process) 14:28:38 <ralonsoh> is to introduce two listeners in the servers 14:28:49 <ralonsoh> one with and another one without namespace 14:29:05 <ralonsoh> ^^ during 2 releases 14:29:10 <slaweq> but then mtomaska will still need to go with 1) approach for his patch 14:29:18 <ralonsoh> yes 14:29:27 <slaweq> ralonsoh please remember about SLURP releases :) 14:29:28 <ralonsoh> that is straightforward 14:29:47 <ralonsoh> slaweq, C will start with the migration 14:29:56 <ralonsoh> and E will keep them 14:29:59 <ralonsoh> yes, sorry 14:30:05 <ralonsoh> 2 SLURP releases 14:30:11 <ralonsoh> so 4 in total 14:31:10 <slaweq> 3 in total: C (SLURP), D (non SLURP) and E (SLURP) :) 14:31:56 <slaweq> so what I propose is: 14:32:18 <slaweq> 1. try to use namespaces and test it with grenade jobs to see how it works 14:32:43 <mtomaska> 1. I did that already. see patchset 9. grenade passed 14:32:45 <slaweq> 2. if that will work fine we can go with this approach IMHO, if there will be problem with upgrade as we are expecting, we will need to: 14:33:33 <slaweq> 3. do what ralonsoh said about two listeners for now and You should then go with different name of Your callback method in Your patch mtomaska 14:34:14 <ralonsoh> grenade is updating all services at the same time 14:34:23 <mtomaska> I also need that patch for downstream 16.2 async release :) 14:34:24 <ralonsoh> we don't have updated API and old agents 14:34:32 <mtomaska> and 17.1.3 14:34:36 <slaweq> mtomaska You changed that namespace for DHCP agent only 14:34:50 <slaweq> and in grenade job this agent is only running on controller which is updated 14:35:07 <mtomaska> slaweq, o ok, you mean change all namespaces 14:35:08 <slaweq> on "compute" node, which is not upgraded to new version there is ovs agent running 14:35:40 <slaweq> mtomaska yes, You will need to change at least namespace used by the OVS agent to test with grenade job 14:35:47 <slaweq> and/or metadata agent 14:35:52 <ralonsoh> exactly 14:36:01 <slaweq> and L3 agent 14:36:15 <slaweq> those 3 are running in compute1 node: https://7b4153b100b6f570d4fc-1ca4271300c9fb8c2811a73921fc79fe.ssl.cf2.rackcdn.com/903572/9/check/neutron-ovs-grenade-multinode/d255232/compute1/logs/index.html 14:36:24 <slaweq> but not DHCP agent unfortunately 14:37:03 <ralonsoh> IMO, for your patch to be merged (and backportable is D/S), the method should be just "get_dhcp_ports" 14:37:18 <ralonsoh> the RPC namespace should be another LP bug 14:37:26 <ralonsoh> this is not trivial 14:38:11 <mtomaska> yes, a simple change is snowballing :) 14:38:34 <ralonsoh> perfect! thanks slaweq for the grenade information 14:38:53 <ralonsoh> I'll open a RFE to cover the RPC namespace changes 14:38:57 <mtomaska> ok. Let me rename it to get_dhcp_ports . Then I will document what we discussed here in a LP 14:39:20 <ralonsoh> mtomaska, will you open this LP bug? 14:39:24 <mtomaska> yes 14:39:30 <ralonsoh> perfect 14:39:39 <mtomaska> thank you for the info all 14:39:58 <ralonsoh> anything else you want to bring to the on demand section? 14:40:20 <ralonsoh> 2 heads-up 14:40:30 <ralonsoh> in 20 mins we have the CI meeting here in this channel 14:40:37 <ralonsoh> and I forgot the bug deputies 14:40:43 <ralonsoh> This week elvira is the bug deputy, next week will be slaweq 14:40:49 <ralonsoh> ack ^? 14:41:06 <slaweq> sure 14:41:17 <ralonsoh> I'll ping elvira offline 14:41:27 <ralonsoh> thank you all, see you 14:41:35 <ralonsoh> #endmeeting