14:00:05 #startmeeting networking 14:00:06 Meeting started Tue May 21 14:00:05 2019 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:10 The meeting name has been set to 'networking' 14:00:15 o/ 14:00:17 o/ 14:00:18 o/ 14:00:29 o/ 14:02:04 ok, let's get going 14:02:13 o/ 14:02:19 #topic Announcements 14:02:58 The next milestone in June 3 - 7 14:03:02 Train 1 14:03:11 so it is not that far away 14:03:25 a little more than 2 weeks away 14:03:45 This is the complete Train schedule: 14:03:49 #link https://releases.openstack.org/train/schedule.html 14:03:56 hi 14:05:08 The call for papers for teh Shanghai Summit is open. The deadline for proposals is July 2nd: 14:05:10 hi 14:05:12 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006262.html 14:06:17 and here's a couple of picyures of a bunch of very handsome gentlemen from the recent Denver PTG: 14:06:23 #link https://www.dropbox.com/sh/fydqjehy9h5y728/AAC1gIc5bJwwNd5JkcQ6Pqtra/Neutron?dl=0&subfolder_nav_tracking=1 14:06:52 Mass quits on the pictures.... Ouch 14:06:57 oops netsplit 14:07:21 come on these pictures are not *that* scary ;) 14:07:52 Was thinking on making the rainbow hair a staple ;) 14:08:00 One thing to note is that we don't have ladies in the team anymore 14:08:23 we are a bunch of bros 14:08:58 Finally, I sent out the PTG summary to the ML: 14:09:02 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006408.html 14:09:41 Please look at your sections of interest. Hopefully, I captured most of the topics faithfully 14:09:54 and thanks to davidsha for the great notes taking 14:10:15 thanks to you both for the great notes 14:10:33 thanks for the great summary! 14:10:38 ++ 14:10:50 np, thanks for summary! 14:11:00 +2 on the notes, thanks mlavalle 14:11:00 yes, thx for great summary :) 14:11:18 We will keep the pointer to the notes in the announcements section of our agenda for the rest of the cycle 14:11:43 any other announcements? 14:12:18 ok, let's move on 14:12:24 #topic Blueprints 14:12:59 netsplit rejoin 14:13:15 This is what I have so far in the Train-1 dashboard: 14:13:20 #link https://launchpad.net/neutron/+milestone/train-1 14:14:08 On https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch 14:15:07 I want to mention that I will start this one taking one weekly bite out of https://review.opendev.org/#/c/545501/ 14:15:39 I will rebase it later today 14:15:52 so he have a recent picture out of it 14:16:19 mlavalle: How do you want to plit the work between you, ralonsoh, and me? The thing about engine facade switch is that when you change a high level function you have to delve through things it calls to make sure they are also using the facade, otherwise Bad Stuff can happen. 14:16:23 *split 14:16:41 and afterwards, if any of you want to nibble out of it, just leave a comment in the patch in the corresponding file 14:16:47 njohnston: how about ^^^? 14:16:59 mlavalle: cool, sounds good 14:17:35 and as we merge patches, keep rebasing this one 14:17:39 makes sense? 14:17:48 yes 14:17:53 definitely. 14:18:20 no promise but I'll try to take a few bites off if I get time 14:18:53 thanks to the 3 of you :-) 14:19:31 On https://blueprints.launchpad.net/neutron/+spec/smart-nic-ovs 14:20:47 I see that slaweq, tidwellr_ and njohnston reviwed the patch 14:21:03 and something got wrong with the latest revision 14:21:12 but we are moving forward 14:21:14 yes, I think that it's quite close to be ready in overall 14:21:27 I was also talking with hamdyk about it today on IRC 14:21:39 so thanks for keeping it moving forward 14:22:05 I also talked to him a few weeks ago. He is in the West Bank, Palestine 14:22:13 we don't get many devs from there 14:23:20 in regards to https://blueprints.launchpad.net/neutron/+spec/multiple-segment-per-network-per-host 14:23:48 thanks rubasov and lajoskatona for taking a look at the spec: https://review.opendev.org/#/c/657170 14:24:11 mlavalle: no problem 14:24:17 of course 14:24:32 last time I looked at it (about a week ago) it seemed to me he still needs help fleshing out the non linuxbridge parts 14:24:51 this week I will try to help with ovs 14:25:10 rubasov, lajoskatona: could you help him with sr-iov? 14:25:49 of should we reach out to Adrian Chiris of Mellanox? 14:26:03 mlavalle: perhaps, sadly we have no hardware for it, so with limited possibilities 14:26:22 ok, I'll ping Adrian 14:26:29 mlavalle: I'm in the same shoes as lajoskatona 14:27:28 Finally, about https://blueprints.launchpad.net/neutron/+spec/event-notifier-ironic 14:27:28 mlavalle: but otherwise hope that we can help in this feature 14:28:48 I can see that hjensas is moving fast, as usual: https://review.opendev.org/#/c/658787/ 14:29:10 thanks ralonsoh and slaweq for the reviews :-) 14:29:18 mlavalle: sure :) 14:29:24 np 14:30:03 I will be going over the PTG summary again this week and will add more blueprints that we need to track 14:30:16 any other blueprints we should discuss today? 14:30:45 the extraroute improvement spec has an open question 14:31:04 that could use more opinions 14:31:12 http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006440.html 14:31:22 https://review.opendev.org/655680 14:32:18 rubasov: I'll take a stab today 14:32:30 yeah, it raised an open question on the router abstraction. 14:32:36 mlavalle: thanks a lot 14:33:06 amotoki: I'm also trying to involve heat folks, since they raised the use case 14:33:47 rubasov: thanks for looping them in. we would like to see a good consensus. 14:34:35 ok, moving on 14:34:47 #topic Bugs 14:35:40 Last week our deputy was tidwellr_ 14:35:52 hi 14:35:59 his report is here: 14:36:03 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006410.html 14:36:31 it seems it was a relatevile quiet week 14:36:49 unless I missed something, yes :) 14:37:29 I want to highlight https://bugs.launchpad.net/neutron/+bug/1824571 14:37:30 Launchpad bug 1824571 in neutron "l3agent can't create router if there are multiple external networks" [Critical,Confirmed] - Assigned to Miguel Lavalle (minsel) 14:37:38 This isn't from last week 14:37:52 but was recently promoted to critical by slaweq 14:38:01 so I am looking at it now 14:38:03 yes, I know that at least couple of people hit this recently 14:38:43 mlavalle: let me know if you need help, although a fix wasn't quickly obvious to me 14:38:59 haleyb: thanks 14:39:51 in regards to the RFE from last week: https://bugs.launchpad.net/neutron/+bug/1829449 14:39:52 Launchpad bug 1829449 in neutron "Implement consistency check and self-healing for SDN-managed fabrics" [Undecided,New] 14:40:06 I'd also like to highlight https://bugs.launchpad.net/bugs/1829042 just because it missed the report 14:40:07 Launchpad bug 1829042 in neutron "Some API requests (GET networks) fail with "Accept: application/json; charset=utf-8" header and WebOb>=1.8.0" [Undecided,New] 14:40:50 this is the result of a conversation I had with Jacob in Denver 14:40:56 njohnston: yes, I did forget to include that one in the report as I was compiling it 14:41:10 so thanks to tidwellr_ and slaweq for commenting on it 14:41:30 mlavalle: you have some more insight into this? 14:42:28 and yes, njohnston thanks. Iwasn't going to skip it. I was going to point to bcafarel's message: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006429.html 14:42:43 thanks mlavalle, sorry for jumping the gun :-) 14:43:07 tidwellr_: not much more of what is in the report. I asked Jacob to submit so we can flesh it out as a team 14:43:53 mlavalle: thanks, I guess we wait :) 14:44:22 any other bugs we should discuss today? 14:45:22 https://bugs.launchpad.net/neutron/+bug/1829414 came up in the report, I'm not sure what to make of it since I can't conceive of a real-life scenario where this occurs, but it is interesting 14:45:23 Launchpad bug 1829414 in neutron "Attribute filtering should be based on all objects instead of only first" [Medium,In progress] - Assigned to Tom Stappaerts (tstappae) 14:45:57 Perhaps https://bugs.launchpad.net/neutron/+bug/1828543 14:45:58 Launchpad bug 1828543 in neutron "Routed provider networks: placement API handling errors" [Medium,New] - Assigned to Lajos Katona (lajos-katona) 14:46:21 thanks for bringing them up 14:46:26 let's move on 14:46:26 I started a discussion on ml: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006377.html 14:47:04 This week's deputy is Swami. I already exchanged emails with him, so he is on it 14:47:14 and next week it is amotoki's turn 14:47:20 it seems that placement started to use some guide from API-SIG, and nobody else follows that, not even keystonauth, perhaps some advice, would be good how to proceed as it seems to be a xproject problem 14:47:56 lajoskatona: I will add my two cents soon 14:48:14 mlavalle: thanks 14:48:18 #topic neutron-lib 14:48:35 boden: you around? 14:48:36 hi 14:49:08 business as usual; working some consumption patches, but have been going a little slow as it seems the gate has been fussy 14:49:49 I don't see any items worth disucssing, unless someone has something? 14:50:15 not from me 14:50:45 I will note that we got 14 inches of snow last night in colorado!! : 14:50:52 be glad you already came to the PTG :) 14:50:55 that's it 14:50:57 yowza 14:50:59 LOL 14:51:11 almost summer 14:51:15 winters here 14:51:36 so the few snowflakes we got for the summit were really nothing :) 14:51:37 :D 14:51:51 #topic On demand agenda 14:52:03 njohnston, ralonsoh: you are up 14:52:15 very quick 14:52:19 OK, so this has to do with everyone's favorite topic: OVO. 14:52:28 njohnston, please 14:52:31 yaay! 14:53:12 In change https://review.opendev.org/#/c/658155/ ralonsoh proposed removing old OVO compatibility code for QOS objects. The OVO compatibility code is meant to facilitate rolling upgrades so that a server can communicate with an agent when the version difference is 1-off. 14:53:23 Therefore there should not be any need to keep code beyond 2 cycles after the object version change; all of the changes ralonsoh proposed changing were >1 year old. I think this is useful housecleaning and I wanted to suggest to the community that we undertake such cleaning more broadly. 14:54:14 My main concern is that unnecessary evaluation for potential downgrades may slow down RPC messaging 14:54:23 ralonsoh: your turn 14:54:50 as I commented in the agenda, first I'll submit a doc in devref with examples for future developments 14:55:02 +1 from me 14:55:09 then I'll clean those compatibility functions not needed anymore 14:55:14 we should support N -> N+1 upgrades, right? 14:55:50 N -> N+1 would mean backporting changes wouldn't it? 14:55:54 slaweq: Correct, we're only talking about code that would be N -> N+2,N+3,etc 14:56:02 slaweq, if someone add new modifications, this person will need to add the conversion methods 14:56:24 but what we don't support is N -> N-1 with older versions (>1 year) 14:56:51 It makes sense to me 14:56:53 and that's all, if you accept it 14:56:57 to put it another way: we don't need code in Train to handle an object version we added in Pike 14:57:04 ralonsoh: yes, I maybe did too big shorcut here :) 14:57:04 correct 14:57:05 njohnston, exactly 14:57:15 I agree with what You said 14:57:32 do we support only N->N+1 in RPC messaging? 14:57:50 I thought so..... 14:57:52 it means all compute nodes should be upgraded before upgrading N+2 14:58:15 amotoki: I believe that is all we have ever promised. I went back and reviewed the old summit presentations about rolling upgrades, and that was the offered solution 14:58:18 amotoki, we support N > N+1 and N >N-1 if versions have less than 1 year 14:58:29 sorry, not N > N+1 14:58:35 always downgrade 14:58:48 I was thinking 14:58:57 I understand the upstream community only ensure N->N+1 upgrade. 14:59:13 for example db migration only supports N->N+1 14:59:33 only one version difference, yes amotoki 15:00:16 ok, guys, we ran out of time 15:00:20 thanks for attending 15:00:24 I think guaranteeing N->N+1 upgrade and support only N->N+1 are differnt a bit 15:00:25 have a great week 15:00:25 Thanks 15:00:33 bye! 15:00:34 let's contineu this discussion somewhere 15:00:37 #endmeeting