14:00:56 <haleyb> #startmeeting networking
14:00:56 <opendevmeet> Meeting started Tue Feb 20 14:00:56 2024 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:56 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:56 <opendevmeet> The meeting name has been set to 'networking'
14:00:58 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki
14:00:59 <mlavalle> \o
14:01:07 <slaweq> o/
14:01:07 <ralonsoh> hello
14:01:08 <obondarev> hi
14:01:09 <elvira> o/
14:01:15 <frickler> \o
14:01:20 <rubasov> o/
14:01:21 <mtomaska> can't attend today :/
14:01:28 <ykarel> o/
14:02:14 <haleyb> ok, we can get started
14:02:19 <haleyb> #topic announcements
14:02:30 <haleyb> #link https://releases.openstack.org/caracal/schedule.html
14:03:07 <haleyb> General libraries (except client libraries) need to have their last feature release this week
14:03:19 <lajoskatona> o/
14:03:23 <haleyb> i have seen proposals for neutron-lib, etc
14:03:34 <haleyb> we still had a few things in neutron-lib to merge i think
14:03:42 <haleyb> #link https://review.opendev.org/q/project:openstack/neutron-lib+status:open
14:03:56 <ralonsoh> please lets focus on these open reviews
14:04:19 <haleyb> yes, i will look right after meeting
14:05:04 <haleyb> Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (February 29, 2024)
14:05:14 <haleyb> i dont think that really affects us
14:05:30 <haleyb> Feb 26th-Mar 1st is C-3 milestone / feature freeze / requirements freeze
14:06:35 <haleyb> to complicate things (for me) i'm out this wednesday and friday, they didn't ask my kids school when to have break :)
14:07:05 <mlavalle> in regards to the neutron-lib reviews list. there are some that go as far as July of last year. Are those also priorities?
14:07:56 <ralonsoh> the ones already reviewed and with zuul+1
14:08:06 <mlavalle> ack
14:08:45 <lajoskatona> +1
14:12:01 <haleyb> i did have a question on the unmaintained core group after seeing a ML email on it
14:12:12 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/ID6BUMR7XCGQQ6LPNLGYGPHCJAFYWJ5I/
14:13:13 <haleyb> To summarize: you should only create your own separate group if you want
14:13:13 <haleyb> to maintain the unmaintained branches yourself and don't want the larger
14:13:13 <haleyb> group to do it for you.  Otherwise you have no such obligation.  If you
14:13:13 <haleyb> are interested in helping with the unmaintained branches, it will help
14:13:14 <haleyb> the community more if you join the global team instead creating your own.
14:13:43 <haleyb> i haven't seen a follow-on to that yet
14:14:07 <lajoskatona> thanks haleyb, so we have to ask permisison to that big group
14:14:36 <ralonsoh> we should request a Neutron core vote for this
14:14:36 <lajoskatona> and we will have "root" permisison on all projects unmaintained/yoga now :-)
14:14:36 <frickler> well ... "big" ;)
14:14:52 <lajoskatona> frickler: :-)
14:15:06 <ralonsoh> if 1) we want a independent group or 2) join the global one
14:15:12 <lajoskatona> not big by members but big by repsitiories?
14:15:21 <frickler> yes, that may be true
14:15:43 <ralonsoh> if there is no quorum today, we can delay it to the next drivers meeting
14:15:52 <ralonsoh> (but I think we have quorum)
14:16:18 <slaweq> ralonsoh neutron cores have (should have) nothing to do/vote here - unmaintained branches were created to free core groups from maintaining those old stuff
14:16:42 <ralonsoh> but we are deciding if creating a neutron um group or not
14:16:51 <ralonsoh> should this should be decided by neutron core
14:17:10 <slaweq> IMO this should be decision of the people who wants to maintain those branches
14:17:44 <ralonsoh> ok, then, I'll abandon the proposed patch https://review.opendev.org/c/openstack/project-config/+/908911 and leave to anyone independently to join the "big" group
14:17:51 <slaweq> it is not neutron core group decision, can be if core team really wants to maintain it but the goal of unmaintained branches was different really
14:17:58 <haleyb> right, last week we started the process, but after that email i had a pause, since it would mean this core group would be the approvers
14:18:14 <slaweq> so I want it to be clear here - neutron core team IS NOT responsible for unmaintained branches at all
14:18:21 <ralonsoh> yes, I know
14:18:29 <ralonsoh> but the creation (or not) of this group is
14:18:36 <opendevreview> Merged openstack/ovsdbapp master: Update supported python versions  https://review.opendev.org/c/openstack/ovsdbapp/+/903993
14:18:38 <ralonsoh> --> https://review.opendev.org/c/openstack/project-config/+/908911
14:21:00 <haleyb> slaweq: so if we create the group, it's only that group that can merge neutron* things, correct?
14:21:19 <slaweq> haleyb yes
14:21:21 <haleyb> we then would each, if desired, need to join said group
14:21:46 <slaweq> if anyone would be interested in doing so, then yes
14:22:04 <slaweq> but by default neutron core group or PTL shouldn't be core in that group automatically
14:22:25 <slaweq> to not have any impression that core team is responsible for such branch
14:22:36 <frickler> you could also modify the acls to include openstack-unmaintained-core. but then the new group would be kind of redundant
14:23:04 <haleyb> slaweq: right, but it might just happen that way
14:23:29 <slaweq> haleyb yes, it can but not by default :)
14:23:46 <slaweq> and I would really want to avoid doing it that way
14:24:02 <slaweq> as then it will be no real change comparing to current EM thing
14:24:48 <mlavalle> yeap, why make the change then
14:25:44 <slaweq> mlavalle are You asking why is the "unmaintained" change done at all?
14:27:23 <haleyb> i think we have 6 (or 7?) cores here, do we want to vote?
14:27:32 * haleyb was trying to wait for response there
14:27:39 <haleyb> if 1) we want a independent group or 2) join the global one
14:28:03 <frickler> or 3) ignore unmaintained branches completely?
14:28:44 <mlavalle> slaweq: I was just agreeing with you
14:28:53 <slaweq> mlavalle ok :)
14:29:07 <ralonsoh> 2) is a personal option, option 3) is by default now
14:29:18 <haleyb> frickler: last week we agreed there were some of us that didn't want that
14:29:28 <slaweq> haleyb are You asking if we as neutron cores want to join unmaintained group or create neutron unmaintained group and be part of it?
14:29:35 <ralonsoh> no
14:29:45 <ralonsoh> we are not asking anyone to join this group
14:29:58 <ralonsoh> but, of course, if no one is joinin it, it makes no sense
14:30:07 <haleyb> right, just if we wanted to make our own, i.e. merge that patch
14:30:20 <ralonsoh> ok, let's finish this topic
14:30:38 <ralonsoh> anyone is able to join the "big" group if needed
14:30:50 <ralonsoh> I'll abandon the creation of this neutron um group
14:30:53 <lajoskatona> ack, and unsetood
14:30:54 <ykarel> +1
14:30:57 <ralonsoh> we'll retake it if needed
14:30:58 <haleyb> +1
14:31:06 <mlavalle> +1
14:31:16 <ralonsoh> done
14:31:39 <haleyb> alright, anything else for announcements?
14:31:55 <haleyb> #topic bugs
14:32:09 <haleyb> rubasov was bug deputy last week
14:32:13 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/35WCRUGK3BD54NYJ2U6BEB5WHLJ5SHXO/
14:32:34 <rubasov> there's one unassigned bug
14:32:35 <slaweq> haleyb one thing to announcements
14:32:37 <slaweq> quickly
14:32:49 <slaweq> there is nomination period of TC and PTLs open already
14:33:03 <slaweq> if anyone is interested, please send Your nominations :)
14:33:05 <haleyb> oh right
14:33:15 <slaweq> that's all from me
14:33:16 <slaweq> thx
14:33:51 <rubasov> so, this ovn bug is unassigned: https://bugs.launchpad.net/neutron/+bug/2053274
14:33:53 <haleyb> i was going to nominate myself for a second term
14:34:14 <slaweq> haleyb++ that's great
14:34:15 <lajoskatona> haleyb: cool, thanks
14:34:16 <haleyb> in case there was someone worried about next release
14:35:08 <mlavalle> haleyb: thanks for your leadership. I wasn't worried just yet, but wondering
14:35:53 <opendevreview> Merged openstack/neutron-tempest-plugin master: Add router check, subnet attached gateway IP update or deletion  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710
14:36:11 <haleyb> no problem, i've just been busy recently
14:36:38 <haleyb> rubasov: ack, i did see that mtu bug, seemed legit
14:37:28 <haleyb> and i think there is a way to address it, just a little complicated after looking at the code
14:37:30 <rubasov> other than that the author of the rfe did not return yet, I don't know if he/she would want to contribute
14:39:39 <haleyb> did anyone want to take that OVN bug? or i can ping the submittor to see if they have cycles?
14:40:26 <haleyb> alright, will drop a note in it
14:40:45 <ralonsoh> I can take it
14:41:14 <haleyb> ralonsoh: ack, thanks
14:41:36 <haleyb> and just my weekly bug housekeeping
14:42:03 <haleyb> Current bug count this week: 745, down 25 from last week's 770
14:42:19 <haleyb> i spent some time closing some, as did ralonsoh i believe
14:42:22 <ralonsoh> (I closed 15 yesterday)
14:42:45 <frickler> saw some pretty old ones fly by, good work
14:43:16 <haleyb> ralonsoh: yes, thanks, when i noticed that i did the same
14:43:34 <haleyb> will scrub some more once we go into freeze
14:43:46 <lajoskatona> +1, I checked also some, but much lower than your numbers :-)
14:44:12 <haleyb> the only good bug is a closed bug :)
14:44:22 <mlavalle> indeed, LOL
14:45:13 <haleyb> this weeks bug deputy is lucasagomes, next week is jlibosva
14:45:29 <haleyb> lucasagomes: you good triaging this week?
14:45:40 <haleyb> i don't see kuba here
14:45:50 <mlavalle> I can ping both internally
14:46:06 <slaweq> haleyb I would go step further and say that the only good bug is invalid bug :P
14:46:41 <mlavalle> naah, we want some feedback from the real world
14:47:01 <haleyb> slaweq: because we don't have bugs in our code, they're just using it wrong :)
14:47:10 <lajoskatona> :D
14:47:24 <slaweq> haleyb exactly :D
14:47:44 <haleyb> alright, lets move on not much time left
14:47:45 <slaweq> it's always PEBKAC
14:47:47 <haleyb> topic #specs
14:47:54 <haleyb> #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open
14:48:12 <haleyb> hmm, bad paste
14:48:37 <haleyb> #link https://review.opendev.org/q/project:openstack-neutron-specs+status:open
14:49:13 <haleyb> strange, still not working for me
14:49:25 <slaweq> first link is ok for me
14:49:31 <ralonsoh> https://review.opendev.org/q/project:openstack/neutron-specs+status:open
14:49:51 <haleyb> that's better
14:50:55 <haleyb> i realize we might not work on these this cycle, but if anyone has time can review
14:51:05 <haleyb> #topic community_goals
14:51:11 <haleyb> #link https://review.opendev.org/c/openstack/horizon/+/891205
14:51:36 <lajoskatona> I had some discussions with gtema from SDK team
14:52:26 <lajoskatona> and based on that I see better what is not working with tls_enabled, but there are still things I just guess there with SDK
14:52:53 <lajoskatona> so still fighting
14:53:00 <haleyb> lajoskatona: ack, thanks for the update
14:53:16 <haleyb> will move on since we have two more items
14:53:20 <haleyb> #topic on_demand
14:53:26 <haleyb> ralonsoh: you had two things here
14:53:52 <ralonsoh> https://review.opendev.org/c/openstack/neutron-lib/+/903971
14:54:05 <ralonsoh> this is incorrectly implementing an API extension
14:54:08 <ralonsoh> as commented in the patch
14:54:25 <ralonsoh> the problem is that this is mimicing what was done before
14:54:56 <ralonsoh> the question is: should we accept it as is now (again wrong) or request a correct (and more complex) implementation?
14:55:04 <ralonsoh> this is affecting neutron-vpnaas
14:55:36 <haleyb> that was my fault for approving
14:55:53 <lajoskatona> I was in it also
14:56:00 <ralonsoh> not at all, there are many reviewers (me too)
14:56:37 <ralonsoh> we are running out of time: please comment in the patch
14:56:39 <ralonsoh> second topic
14:56:52 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/2054203
14:57:02 <ralonsoh> because of a change in netaddr
14:57:12 <ralonsoh> "101.12.13.00/24" is going to be considered as wrong
14:57:34 <ralonsoh> question here: is this an API regression or that was a previous bug
14:57:48 <frickler> or any leading zeros in IP literals general
14:57:48 <ralonsoh> IMO: a previous bug, "101.12.13.00/24" should have never been a valid input
14:57:53 <haleyb> which i think is correct to be a bug, are you worried someone might have been using the api and relied on that?
14:57:56 <ralonsoh> ^^ exactly
14:58:10 <frickler> haleyb: yes
14:58:14 <ralonsoh> yes, that's the point, if anyone is using it now
14:58:53 <ralonsoh> again, we are running out of time, please comment in the LP bug
14:59:02 <tkajinam> that 101.12.13.00 is a specific case which may look like invalid, but please note that the change would reject a few more different patterns like 10/8
14:59:38 <ralonsoh> sorry, I don't understand that one
14:59:39 <tkajinam> that's the core concern and the reason why I said "at least"
14:59:41 <ralonsoh> 10/8?
14:59:50 <tkajinam> 10/8 is translated to 10.0.0.0/8
15:00:09 <ralonsoh> and that was a valid input?
15:00:25 <haleyb> we are out of time, please follow-up in the bug and/or review
15:00:31 <frickler> yes. or just "1". see also https://bugs.launchpad.net/neutron/+bug/2054435 for an related issue that this discovered
15:00:33 <haleyb> but i don't think 10/8 should be valid either
15:00:51 <tkajinam> will post a comment in a bug with some more details
15:00:59 <ralonsoh> thanks
15:01:00 <tkajinam> just wanted to highlight this may not be a trivial bug
15:01:13 <haleyb> #endmeeting