14:00:11 <slaweq> #startmeeting neutron_drivers
14:00:12 <openstack> Meeting started Fri May 29 14:00:11 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:13 <yamamoto> hi
14:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:16 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:16 <slaweq> hi
14:00:17 <mlavalle> o/
14:00:21 <ralonsoh> hi
14:00:38 <amotoki> hi
14:01:10 <njohnston> o/
14:01:47 <slaweq> I just pinged haleyb to join us
14:01:58 <slaweq> and I think we can start as we have quorum definitely
14:02:04 <slaweq> #topic RFEs
14:02:20 <slaweq> We have 2 RFEs (old ones) which I would like to discuss today
14:02:27 <slaweq> https://bugs.launchpad.net/neutron/+bug/1817881
14:02:27 <openstack> Launchpad bug 1817881 in neutron " [RFE] L3 IPs monitor/metering via current QoS functionality (tc filters)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:03:17 <haleyb> hi
14:03:36 <slaweq> spec for that is proposed here: https://review.opendev.org/#/c/658511/
14:03:36 <patchbot> patch 658511 - neutron-specs - L3 agent self-service metering - 10 patch sets
14:04:06 <slaweq> basically, it's about adding new l3 agent extension which will do metering for all ports which has got QoS bandwidth limit enabled
14:04:11 <njohnston> mlavalle: c=x/op
14:04:22 <njohnston> hmm, that was weird, keyboard malfunction
14:04:45 <mlavalle> LOL, I thought you were saying something bad about me or my ancestry
14:05:40 <slaweq> :D
14:06:01 <ralonsoh> basically it's reading the QoS TC info every 30 secs (configurable) and sending it via RPC
14:06:07 <slaweq> njohnston: so x=c*op then :P
14:06:16 <ralonsoh> on those interfaces with QoS TC classes or filters
14:06:36 <mlavalle> that summarizes it
14:06:55 <ralonsoh> looks "easy" (that's never true in Neutron)
14:07:00 <ralonsoh> and harmless
14:07:15 <haleyb> ralonsoh: if i had $1 for everyone that said that :)
14:07:21 <slaweq> :)
14:07:41 <slaweq> haleyb: "and it shouldn't break anything" ;)
14:08:00 <njohnston> Does it need to bind to a Neutron QoS policy in order to use those TC classes and filters?  That seems to still be implied in the spec lines 48-50, despite the conversation on PS4
14:08:36 <ralonsoh> I think so
14:08:53 <ralonsoh> FIP and router QoS implementation is similar, using TC filters
14:09:09 <slaweq> yes, it's required otherwise there is no TC stats to get for the interface
14:09:19 <ralonsoh> kernel will store this info per TC
14:09:21 <ralonsoh> exactly
14:10:07 <njohnston> ok
14:10:41 <slaweq> but this kinds of duplicates what metering agent should do and my question is: what we should do with metering agent? Deprecate it? Keep 2 solutions in-tree?
14:11:01 <slaweq> is metering agent really used in real world?
14:11:13 <amotoki> I have similar questions on the metering agent.
14:11:16 <slaweq> I don't think we are testing it a lot
14:11:35 <ralonsoh> I forgot about this metering agent...
14:11:37 <amotoki> the proposal is compatible with the metering agent or we need to use one of them
14:11:42 <amotoki> ?
14:11:50 <njohnston> Has anyone looked to see if the metering agent works with OVN?
14:12:00 <haleyb> i think the metering agent has some unaddressed bugs, but i had the same question - we have it for this purpose
14:12:24 <amotoki> the current metering agent has only iptalbes driver, so I don't think it works with OVN
14:13:14 <njohnston> the spec also calls out https://bugs.launchpad.net/neutron/+bug/1807157 as a reason not to use the metering agent, in addition to it's inconvenience and extra AMQP load on large deployments
14:13:14 <openstack> Launchpad bug 1807157 in neutron "Metering doesn't work for DVR routers on compute nodes" [Undecided,In progress] - Assigned to Alexandru Sorodoc (bno1)
14:14:01 <njohnston> I would be fine deprecating the current metering agent and moving to a better solution, as I don't think it is widely used for some of these reasons
14:14:24 <njohnston> We'd just have to come up with what we think a better OVS/OVN-based solution would be.
14:15:08 <amotoki> another question is the spec says the new l3 extension send stats via RPC to the metering service.
14:15:10 <amotoki> I wonder whether we need some change in the metering side, or it will use the same metrics as what the metering agent uses.
14:16:32 <slaweq> amotoki: that's good question but I think it can be explored in the spec review
14:17:06 <amotoki> slaweq: yeah, agree
14:17:36 <mlavalle> I think we should approve this RFE and explore all the nuances in the spec
14:17:40 <slaweq> and I agree with njohnston - we can probably deprecate metering agent and go with new, hopefuly better solution
14:17:55 <njohnston> slaweq: PTG topic?  Metering next generation?
14:18:12 <mlavalle> +1
14:18:17 <amotoki> the reason I raised is because I think keeping the notification API to the metering service will lead to a better way for OVN-based solution. in OVN world, we don't need an agent.
14:18:23 <amotoki> +1 (for PTG topic)
14:18:32 <slaweq> so I'm also for approving this spec but it should be written in the spec explicity that this will deprecate old solution, and mayeb send email to ML that we are going to deprecate this old agent
14:20:07 <slaweq> ok, I will add it to the PTG agenda
14:20:09 <njohnston> I would say that this is the start of deprecating the old solution, I don't want to put the whole onus of replacing the old metering solution on this spec
14:20:28 <haleyb> njohnston: you got me thinking of Star Trek now, but yes, could be the next generation is to retire and replace
14:22:13 <slaweq> ok, so my proposal is to approve the rfe as the idea to move forward and I will also ask liuyulong when he will be available at PTG so we can discuss details about this spec and future of metering then
14:22:17 <slaweq> what do You think about that?
14:22:52 <njohnston> +1
14:23:00 <haleyb> +1
14:23:08 <amotoki> +1
14:23:15 <yamamoto> +1
14:23:19 <mlavalle> +1
14:23:27 <slaweq> thx
14:23:34 <slaweq> so we're done with this one
14:23:47 <slaweq> next one is also from liuyulong
14:23:50 <slaweq> https://bugs.launchpad.net/neutron/+bug/1828494
14:23:50 <openstack> Launchpad bug 1828494 in neutron "[RFE][L3] l3-agent should have its capacity" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:24:26 <slaweq> spec is here https://review.opendev.org/#/c/658451/
14:24:26 <patchbot> patch 658451 - neutron-specs - L3 agent capacity and scheduling - 8 patch sets
14:26:07 <slaweq> we discussed about it few times in the past, but personally I still don't feel this "bandwidth" of the router just to limit number of routers hosted by one L3 agent
14:27:56 <njohnston> I think your comment #6 on the LP is an easier way to go: https://bugs.launchpad.net/neutron/+bug/1828494/comments/6
14:27:56 <openstack> Launchpad bug 1828494 in neutron "[RFE][L3] l3-agent should have its capacity" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:28:40 <mlavalle> have we heard any feedback from Yulong about comment 6?
14:29:43 <slaweq> mlavalle: nope
14:29:50 <slaweq> at least I didn't saw anything
14:30:18 <mlavalle> so why don't we ping him, ask for his feedback and based on that we re-evaluate this RFE?
14:30:18 <njohnston> the part of the spec where bandwidth is defined separately per external network (L96-103) to me makes this a more complicated proposal
14:30:29 <haleyb> i would agree, "max routers" is easier to understand, bandwidth seems more of a qos thing
14:30:29 <slaweq> but I wanted to raise it here again because maybe it's only me who don't really feel this proposal
14:31:08 <njohnston> not just you, more info is needed
14:31:25 <mlavalle> I think we should have a little more discussion with Yulong in the RFE to fully understand the proposal
14:31:58 <slaweq> ok, I will ask those questions in the RFE again and will ping him about that
14:32:13 <slaweq> and we will back to this rfe when we will have more info about it from him
14:32:24 <slaweq> is that good plan?
14:32:25 <mlavalle> what do tohers think?
14:32:27 <njohnston> +1
14:33:05 <yamamoto> +1
14:33:06 <slaweq> mlavalle: I hope that "tohers" is just a typo :P
14:33:11 <mlavalle> it is
14:33:29 <haleyb> +1
14:33:34 <amotoki> sounds good
14:33:42 <slaweq> mlavalle: I had to check in the dict what it means :)
14:33:49 <mlavalle> lol
14:34:04 <slaweq> ok, so I think we are good with this one too
14:34:14 <slaweq> and that's all RFEs for today
14:34:23 <slaweq> #topic On Demand agenda
14:34:29 <slaweq> I have one more question to You
14:34:34 <slaweq> related to the PTG
14:34:53 <slaweq> in each PTG room there will be zoom meeting available to use
14:35:09 <slaweq> but there will be also possibility to use https://meetpad.opendev.org/
14:35:20 <slaweq> which is based on opensource jitsi tool
14:35:32 <slaweq> and is somehow integrated with etherpad (I don't know how yet)
14:35:47 <slaweq> and my question to the team is - which tool do You prefer to use next week?
14:37:07 <mlavalle> let's try the opens osurce one
14:37:10 <njohnston> We could try Jitsi now: https://meetpad.opendev.org/NeutronTest
14:37:35 <mlavalle> we can always fallback to zoom if it doesn't work well, can't we?
14:38:21 <haleyb> just don't know if zoom works in China?
14:40:05 <slaweq> ok, quick test done
14:40:13 <slaweq> thx njohnston for opening the meeting :)
14:40:19 <ralonsoh> good tool
14:40:24 <njohnston> nice
14:40:29 <amotoki> it worked well so far, nice :)
14:40:34 <slaweq> mlavalle: I agree that we can start with this meetpad and fallback to zoom if needed
14:40:39 <njohnston> +1
14:40:46 <slaweq> thx for Your help with that :)
14:41:04 <njohnston> :)
14:41:17 <slaweq> anything else You want to discuss today maybe?
14:41:26 <slaweq> if not, I will give You some time back today
14:41:59 <ZhuXiaoYu> sorry, could we talk about my ref bug on launchpad: https://bugs.launchpad.net/neutron/+bug/1880532 ?
14:41:59 <openstack> Launchpad bug 1880532 in neutron "[RFE]L3 Router should support ECMP" [Wishlist,New] - Assigned to XiaoYu Zhu (honglan0914)
14:42:55 <ZhuXiaoYu> And spec file is at https://review.opendev.org/#/c/729532/
14:42:55 <patchbot> patch 729532 - neutron-specs - l3 router support ecmp - 22 patch sets
14:44:14 <ZhuXiaoYu> any advise could be helpful
14:46:46 <slaweq> personally I would like first haleyb and liuyulong to triage this in the RFE before we will discuss it here
14:47:19 <slaweq> but if there are any questions about this rfe, I think now it's also good time to ask them as we have owner of the rfe here
14:47:41 <mlavalle> at first glance, seems to be an interesting idea that we should explore
14:48:13 <haleyb> i just haven't had the time to look at this yet, but do know ECMP support is in latest OVN
14:48:15 <mlavalle> making Neutron more capable to serve more use cases is always a good thing
14:48:17 <haleyb> that's all i know
14:50:08 <slaweq> ZhuXiaoYu: is that only for Octavia? Or are there other, more generic use cases for that?
14:50:48 <yamamoto> midonet virtual routers support ecmp. i vaguely remember it can be programmed with neutron extra routes api.
14:51:44 <ZhuXiaoYu> Currently it's really done for Octivia.
14:51:54 <ralonsoh> if kernel supports that
14:52:01 <ralonsoh> yamamoto, right?
14:52:27 <yamamoto> ralonsoh: "vaguely remember"
14:52:51 <yamamoto> ralonsoh: i'm sure "midonet virtual routers support ecmp" part
14:53:23 <ralonsoh> always a pleasure to talk to you
14:54:04 <mlavalle> to me Octavia is enough of a use case
14:54:24 <njohnston> I agree
14:55:06 <slaweq> sure, but I just wanted to know if there are any others
14:55:23 <yamamoto> i mentioned midonet because i'm wondering why the extension is necessary
14:55:44 <yamamoto> maybe i should read the spec :-)
14:56:18 <slaweq> yamamoto: in the spec there is also comment about that this should be doable with our current API
14:56:54 <yamamoto> slaweq: ok it makes sense
14:57:49 <slaweq> so lets all read the RFE and spec and we will get back to this one on next meeting
14:57:53 <slaweq> are You ok with that?
14:58:02 <yamamoto> +1
14:58:02 <mlavalle> yes
14:58:06 <njohnston> +1
14:58:09 <amotoki> +1
14:58:28 <slaweq> btw. I'm going to cancel next week's meeting as we have ptg
14:58:37 <slaweq> so next drivers meeting will be in 2 weeks
14:58:47 <mlavalle> let's make sure is the first topic next week, so ZhuXiaoYu gets enough time
14:58:52 <ZhuXiaoYu> ok
14:58:54 <slaweq> thx for attending the meeting
14:58:56 <ZhuXiaoYu> thx
14:58:59 <slaweq> mlavalle: yes, it will be
14:59:05 <mlavalle> +1
14:59:11 <slaweq> see You all on the PTG next week
14:59:15 <mlavalle> ZhuXiaoYu: that will be in two weeks from now
14:59:19 <slaweq> and have a great weekend
14:59:28 <slaweq> #endmeeting