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