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