14:00:18 #startmeeting neutron_drivers 14:00:19 Meeting started Fri Jul 10 14:00:18 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:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:21 hi 14:00:23 The meeting name has been set to 'neutron_drivers' 14:00:27 hi 14:00:42 hi 14:00:53 Hi 14:01:42 o/ 14:01:46 o/ 14:01:53 lets wait few more minutes for amotoki 14:02:25 first of all, as not many of You were here last week, please welcome ralonsoh as our new team member :) 14:02:34 thanks! 14:03:21 welcome 14:03:31 thank you 14:03:37 ok, I think we can start now 14:03:40 #topic RFEs 14:03:51 we have couple of RFEs for today 14:03:56 first one is from ralonsoh 14:04:07 https://bugs.launchpad.net/neutron/+bug/1886798 14:04:07 Launchpad bug 1886798 in neutron "[RFE] Port NUMA affinity policy" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) 14:04:12 #link https://review.opendev.org/#/c/740011/ 14:04:36 I still need to address some comments from Sean 14:05:06 the goal is to add a new paratemer in the port description, "numa_affinity_policy" 14:05:18 that can be None, legacy, preferred or required 14:05:35 that will work the same a PCI numa policies, but for all type of ports 14:06:06 please, ask me if you have questions 14:06:39 tbh for me it's ok to approve this rfe as we already discussed that in the past 14:06:53 and imo we can clarify some details in the spec's review 14:06:58 perfect 14:07:12 +1 14:07:24 i have no objection 14:07:58 but in sake of procedures I wanted to add it to our agenda for today :) 14:08:04 thank you all 14:08:13 +1 14:08:34 ok, so I think we are good with that one 14:08:44 I will mark it as approved today 14:09:05 and I think we can move on to the next one 14:09:07 https://bugs.launchpad.net/neutron/+bug/1880532 14:09:07 Launchpad bug 1880532 in neutron "[RFE]L3 Router should support ECMP" [Wishlist,New] - Assigned to XiaoYu Zhu (honglan0914) 14:10:25 I'm here today, ask me if you have any question 14:10:33 welcome ZhuXiaoYu :) 14:10:48 :) 14:12:31 since we plan to use iptables to do this, I think it should have a separate API 14:13:54 And I don't want to destroy the original logic of extraroute. 14:14:59 i don't understand. iptables is just an implementation. 14:16:21 yamamoto: so it's the same for me, I'm still not convinced that we need new parameters for that 14:18:05 I think it's not like what extraroute does anymore, yamamoto san 14:19:11 And don't you think that using the original API would add time complexity? 14:20:38 do you mean complexity in a particular iptables-based implementation? 14:21:32 I would have to search every single extraroute entry, even if I just need adding a normal route, I mean 14:21:54 ZhuXiaoYu: I still think that changing existing API to allow routes with same "destination" and different "nexthop" could be maybe better solution 14:22:06 and getting all routes is just one db query always 14:23:50 Well, I'll consider the feasibility of that. 14:24:34 I wonder what others thinks about it 14:24:42 But the logic of the original 'replacement' would have been destroyed. 14:25:02 slaweq's idea could be easier to implement and less intrusive with the current code 14:26:03 ZhuXiaoYu: internally You can check if there is only one route to the destination or more than one and implement it in 2 different ways 14:26:46 or if that would be possible, we can change our existing "replacement" method to something different which will be the same no matter how many routes to the dest we will have 14:27:04 that's how I see it but I may be missing some details which can break this idea :) 14:30:29 I need some time to think about whether this will affect my ability to implement a sustainable hash. 14:31:20 IMO all what You need You can "calculate" in the code when You will get data from the DB 14:32:19 i thought the existing API allowed routes with same "destination" and different "nexthop". at least there seems to be no db constraints to reject them. 14:33:21 yamamoto: that would be even better as that would means that no API changes would be needed at all 14:33:42 Fine, I will change that if wo find it works 14:34:08 if I find it works 14:34:12 sorry 14:34:47 Other questions? 14:34:56 ok, so ZhuXiaoYu please test that and update RFE 14:35:05 and then I think we can get back to it once again 14:35:17 are You all ok with that? 14:35:59 ZhuXiaoYu: when you typed wo, were you thinking 我? 14:36:22 :) 14:36:29 LOL 14:37:00 :) 14:37:07 I had to check in google translate what this means :) 14:37:24 it means `I` 14:37:28 LOL 14:37:58 ok, anyone have any other questions about this RFE for today? 14:38:02 +1 to update the RFE and revisit it again 14:38:12 +1 14:38:21 +1 14:38:39 no more questions from me 14:38:48 great 14:38:56 ZhuXiaoYu: so please test that and comment in the RFE 14:39:05 I will 14:39:10 ZhuXiaoYu: and thx for proposing this :) 14:39:47 ok 14:39:55 that was all what I sent to You yesterday 14:40:07 but today morning one more RFE jumped to the agenda 14:40:15 so as we have some time lets check it 14:40:18 https://bugs.launchpad.net/neutron/+bug/1886949 14:40:18 Launchpad bug 1886949 in neutron "[RFE] Granular metering data in neutron-metering-agent" [Undecided,In progress] - Assigned to Rafael Weingartner (rafaelweingartner) 14:41:29 now we have two new proposals to change/evolve the metering 14:42:15 yes, we have improved liuyulong's RFE to add some metering based on tc counters into the L3 agent 14:42:34 but now it seems that metering agent is used by someone really :) 14:42:59 and as it isn't deprecated (yet) IMO it's worth to discuss this RFE 14:43:24 and this idea of adding "granularity" could be used in the L3 agent too 14:43:36 for lp#1886949 14:45:39 ralonsoh: You mean to reuse granularity proposed here in the liuyulong's proposal? 14:45:50 I can certainly see how the data would be useful 14:45:52 no, the one proposed in this RFE 14:46:20 Rafael is proposing to make the metering message for "flexible", adding more information 14:46:47 that could be an idea, to have tags about the type of info you want transmit 14:47:00 *want to transmit 14:49:23 looking at the proposed change of the message format I'm not sure if we need another config knob for that 14:49:51 we could maybe simply add some new fields to the existing message so it would be backward compatible always 14:49:54 wdyt? 14:50:53 would the receiving end be confused by the "new fields"? 14:51:26 idk 14:51:47 that is good question indeed :) 14:51:55 Does this granularity imply an increase in the number of emssages sent to the notification queue? 14:52:14 i wonder how much the new format can increase ceilometer traffic for real deployments 14:52:38 If message volume will increase that is something that an operator might want to be able to turn off, if their RabbitMQ is stressed. 14:52:51 yeap 14:54:57 ok, that are all good questions to the owner of the RFE :) 14:55:18 can You post them in the RFE comments or do You want me to summarize it and post a comment there? 14:55:50 why not just point to the relevant section of this meeting's log? 14:56:11 mlavalle: sure, I can do that too :) 14:56:56 ok, so I will write a comment there and we can get back to the discussion when we will have replies for those comments 14:57:06 sounds good 14:57:16 +1 14:57:22 that's all what I have for today 14:57:35 one quick announcement at the end 14:57:50 next 2 weeks I will be off so I asked mlavalle to chair this meeting 14:57:57 thx mlavalle for help with that 14:58:02 :-) 14:58:07 Have a great vacation slaweq! 14:58:11 thx 14:58:16 have a great weekend all 14:58:22 and see You in 2 weeks :) 14:58:24 o/ 14:58:28 #endmeeting