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