14:01:22 <slaweq> #startmeeting neutron_drivers
14:01:23 <openstack> Meeting started Fri Jan 22 14:01:22 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:25 <slaweq> hi
14:01:27 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:28 <mlavalle> o/
14:01:35 <jkulik> o/
14:01:36 <seba> hi
14:01:52 <ralonsoh> hi
14:02:19 <slaweq> let's wait few more minutes for amotoki, njohnston, haleyb and yamamoto
14:02:29 <slaweq> as we need to have quorum
14:02:31 <njohnston> o/
14:02:32 <haleyb> hi, thanks for the ping
14:02:36 <slaweq> hi :)
14:03:09 <obondarev> hi
14:04:03 <slaweq> ok, I think we can start
14:04:14 <slaweq> #topic RFEs
14:04:21 <slaweq> we have 1 rfe to discuss today
14:04:25 <slaweq> https://bugs.launchpad.net/neutron/+bug/1911126
14:04:28 <openstack> Launchpad bug 1911126 in neutron "[RFE][L3] add ability to control router SNAT more granularly" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:05:35 <ralonsoh> is Liu here?
14:06:56 <slaweq> I think he's not
14:07:21 <slaweq> but we can still discuss it now and left some questions comments in the rfe
14:07:40 <ralonsoh> ok, I'll start then
14:07:41 <mlavalle> he hasn't shown up lately for other of his RFEs
14:07:52 <ralonsoh> I agree with the RFE but not with the architecture
14:08:05 <ralonsoh> --> https://bugs.launchpad.net/neutron/+bug/1911126/comments/4
14:08:06 <openstack> Launchpad bug 1911126 in neutron "[RFE][L3] add ability to control router SNAT more granularly" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:08:46 <ralonsoh> I think we should explore using TC to mark the traffic, depending on the range of IPs and use this mark with tc-tc to shape it
14:08:53 <ralonsoh> of course, I didn't have time to test it
14:09:16 <ralonsoh> I'm saying this because with this implementation we don't need to change the architecture but the qos extension only
14:09:25 <ralonsoh> and this will be more transparent
14:09:45 <mlavalle> what do you mean by changing the architecture?
14:10:15 <ralonsoh> using FIPs to handle the qos shaping
14:10:37 <ralonsoh> according to the spec, there are groups of internal IPs mapped into FIPs
14:10:56 <ralonsoh> that FIPs will be used by TC to filter the packets and shape them
14:10:58 <mlavalle> yeah, that threw me off a bit also
14:11:27 <ralonsoh> but, of course, I still need to prove that my idea works
14:11:37 <mlavalle> but then in LP he clarifies that "FIP" was really just nomenclature
14:11:57 <ralonsoh> but still we need to "reserve" this IP in the external network
14:12:04 <mlavalle> yeah
14:12:07 <mlavalle> of course
14:12:07 <ralonsoh> this is something we currently don't consider
14:12:54 <mlavalle> so I say we agree on the RFE and debate the implementation in the spec?
14:12:58 <ralonsoh> exactly
14:13:09 <njohnston> +1
14:13:12 <ralonsoh> +1 to the RFE (more discussion in the spec)
14:13:16 <mlavalle> so I say let's go ahead and approve the RFE
14:13:32 <mlavalle> and fight the concept to death in the spec
14:13:37 <slaweq> that's fast :)
14:13:37 <njohnston> lol
14:13:51 <haleyb> +1 since i was also curious when address groups were mentioned
14:14:00 <haleyb> but that's implementation
14:14:11 <slaweq> yes, that is implementation thing
14:14:23 <slaweq> I'm also ok to approve this rfe as the idea
14:14:50 <njohnston> it's definitely an intriguing idea.  It'll be interesting as we debate the spec to get their learned experience since they have implemented it already.
14:15:25 <mlavalle> yes, in the spec debate we should keep in mind they already have experience with the implementation
14:16:29 <slaweq> so, we already decided to approve that rfe and continue discussion about implementation in the spec review
14:16:45 <slaweq> I will mark that rfe as approved after the meeting
14:17:09 <slaweq> any other questions/comments about that rfe, or can we move on?
14:19:19 <mlavalle> let's move on
14:19:28 <slaweq> ok
14:19:36 <slaweq> #topic On Demand agenda
14:19:46 <slaweq> we have one topic added by jkulik
14:19:50 <slaweq> welcome jkulik :)
14:19:53 <slaweq> https://bugs.launchpad.net/neutron/+bug/1791233
14:19:55 <openstack> Launchpad bug 1791233 in neutron "Redundant dynamic partial segments was allocated for the same network and physical_network" [Undecided,New]
14:20:12 <slaweq> please speak about what You wanted to discuss
14:20:22 <jkulik> hi o/
14:20:40 <jkulik> we think we found a bug and proposed to add a constraint to the DB to fix it
14:21:00 <jkulik> it's a race condition and I can't explain it better here than already in https://bugs.launchpad.net/neutron/+bug/1791233/comments/3
14:21:01 <openstack> Launchpad bug 1791233 in neutron "Redundant dynamic partial segments was allocated for the same network and physical_network" [Undecided,New]
14:21:43 <jkulik> we got some feedback already and in there, it was pointed out that we should propose that solution in the neutron drivers meeting
14:22:07 <jkulik> we would like to implement it, but only if you folks feel it's the right approach
14:22:33 <jkulik> this being a race-condition, it's hard to write a unit-test or something for it, I guess
14:23:34 <mlavalle> It seems to me the bug itself has been confirmed by another deployer. So I don't think that is in question
14:23:37 <ralonsoh> and the idea of "local_index"?
14:23:39 <ralonsoh> in c#2
14:23:47 <ralonsoh> (now I remember this bug)
14:24:23 <ralonsoh> I tried using the constrain but does not work with more than one local network
14:24:24 <mlavalle> I say let's go ahead and find a fix. If jkulik has a proposed solution, please send it to gerrit and we can discuss the implementation details there
14:24:37 <slaweq> ralonsoh: I just don't understand exactly what provider segments can local network have
14:24:45 <slaweq> but maybe I'm missing something simply
14:24:52 <ralonsoh> ok, let's push a patch
14:24:59 <ralonsoh> this is indeed a bug
14:24:59 <slaweq> mlavalle++
14:25:03 <jkulik> ralonsoh, I tried to answer in c#3 to your c#2
14:25:05 <mlavalle> it is
14:25:40 <slaweq> I agree, please send patch to review but as bug is already confirmed we need to fix it somehow, db constraint seems good approach IMO
14:25:57 <jkulik> ok. we'll try to do that. thank you
14:26:03 <slaweq> thx jkulik :)
14:26:05 <seba> yeah, thanks from me as well
14:26:08 <mlavalle> I marked the bug as confirmed with mediem riority
14:26:21 <mlavalle> jkulik: will you send a patch
14:26:23 <mlavalle> ?
14:26:30 <jkulik> seba will probably
14:26:43 <slaweq> jkulik: but please keep in mind that any fix which will change db schema will not be possible to backport to stable branches
14:26:48 <mlavalle> ok seba please assign the bug to yourself
14:27:03 <seba> okay, will do
14:27:06 <ralonsoh> ^^ important: DB changes cannot be backported
14:27:18 <jkulik> ok.
14:27:42 <mlavalle> thanks jkulik and seba !
14:28:48 <jkulik> thank you all
14:29:03 <slaweq> thx jkulik and seba for help with that
14:29:16 <slaweq> ok, any other questions, topics to discuss today?
14:29:25 <slaweq> if not, I will give You 30 minutes back :)
14:29:41 <mlavalle> yaay!
14:29:46 <ralonsoh> thanks!
14:29:55 <slaweq> ok, thanks for attending the meeting
14:30:03 <ralonsoh> bye
14:30:03 <slaweq> have a great friday and weekend
14:30:06 <slaweq> see You!
14:30:09 <mlavalle> o/
14:30:10 <slaweq> #endmeeting