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