14:00:05 #startmeeting neutron_drivers 14:00:06 Meeting started Fri Jul 20 14:00:05 2018 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:09 The meeting name has been set to 'neutron_drivers' 14:00:20 o/ 14:00:27 hey njohnston 14:00:31 hi 14:00:36 hi haleyb 14:00:44 ready for the beach? 14:01:22 which beach are you going to? 14:01:33 Cape Cod, I think 14:01:42 mlavalle: almost, have 8-10 softball games to get through first 14:01:53 hi 14:02:04 how long is the drive? 14:02:37 is gooling Cape Cod. looks like a nice place 14:02:42 mlavalle: beach is less than 2 hours 14:03:06 we like it, been there almost every year in forever :) 14:03:35 ok, let's get going 14:03:43 #topic RFEs 14:04:20 First one for today is https://bugs.launchpad.net/neutron/+bug/1757044 14:04:20 Launchpad bug 1757044 in neutron "[RFE] neutron L3 router gateway IP QoS" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) 14:04:56 We discussed it a few weeks ago and were pretty close to approve it. We decided to ask a few questions to improve our understanding of it 14:08:25 I am refreshing my memory. it sounds reasonable to apply QoS policy to an gateway port. 14:08:42 yes, I am for approving it 14:08:54 a question is whether we apply QoS policy for the port or apply QoS policy to an gateway IP. 14:09:39 if we apply QoS policy to a gateway port, it raises another question (whether FIP traffic is included or not when considering QoS) 14:09:59 anyway, it is a reasonable RFE. 14:11:39 He has alsoo been working on the FIP QoS. So I think he is going to keep them separate 14:12:30 haleyb: what do you think? 14:12:51 is looking at his proposed reviews. I agree that he is thinking about per-IP QoS. 14:13:11 mlavalle: i am fine with the RFE 14:13:22 * haleyb was trying to look at reviews too 14:13:52 ok, let's move ahead with it 14:14:03 * mlavalle leaving comment in RFE 14:17:14 hi, sorry late 14:17:16 The next one I want to discuss is out of order, but seems simple to me and we have code alredy in Gerrit: https://bugs.launchpad.net/neutron/+bug/1780370 14:17:16 Launchpad bug 1780370 in neutron "[RFE] Replace the timer based periodic resync task of DHCP agents with an event driven one" [Wishlist,In progress] - Assigned to Kailun Qin (kailun.qin) 14:17:33 welcome Takashi 14:18:06 This is the patch associated to it: https://review.openstack.org/580548 14:18:07 patch 580548 - neutron - Event driven periodic resync task for DHCP agents 14:20:09 mlavalle: there was a good point raised in the review about batching, which i did wonder about as well 14:20:46 yeah, I saw yamamoto's comment. I think we are looking for a middle ground, right? 14:22:39 you could get that with just reducing the retry interval as well... 14:23:02 yeah, agree 14:23:40 yes, that's good point 14:24:11 i guess it's fine to react on an event immediately as far as something ensures that it isn't too frequent. 14:25:14 I agree that we need a mechanism to ensure that it happens too frequently 14:25:45 but we end up with a behavior that is equivalent to just redducing the resynch behavior, wouldn't we? 14:26:02 in that case, why add more coce? 14:26:06 code^^^ 14:26:22 the previous logic does not handle that neither since the interval is configurable 14:26:28 yeah, tend to agree. 14:26:49 kailun: it is or it is not configurable? 14:26:56 is there any actual problem when we use the default 5sec internal? 14:27:15 (or with more smaller interval) 14:27:32 mlavalle: it is I think 14:28:26 so if it is configurable and the deployer reduces the re-synch period, wouldn't we get the same behavior as with event based resynch with a delaying mechanism? 14:29:13 it depends on how frequent the event in question is 14:30:14 if it's usually infrequent, we can react immediately in many cases 14:30:16 we should get a quite similar behavior but not exactly the same 14:30:44 the l3-agent is different, using workers and a queue, and does a more immediate update 14:31:11 Let's say there was an update for something that had not seen an update in a while. The proposed behavior would fire it immediately, whereas if the configured resync interval is 5s then it could be up to 4.9s before that gets propagated in the scheduled case, right? 14:31:45 kailun: so this causes an immediate reaction to a network event, but if nothing happens still does a 5 second sync? 14:31:47 right 14:31:53 that might have been the same question 14:32:02 yes, that should be the case 14:33:47 the patch itself does not change the previous logic but adds with an immediate reaction to a network event if there is one 14:33:59 the current interval is controlled by self.conf.resync_interval, so the question is reducing resync_interval works or not. 14:34:16 kailun: what happens if failure events happen continuously? 14:35:44 that's a good question, as yamamoto's pointed out, a busy-loop I suppose 14:37:04 but the previous logic would end up in this as well if configured with a quite small interval 14:41:20 from RFE perspective, fast recovery would be nice. what I concern is the racing condition. 14:41:32 I am not sure this needs to be discussed as RFE perspective. 14:42:09 in that case, let's just approve the RFE and discuss the details in Gerrit 14:42:14 +1 14:43:05 amotoki, haleyb: you ok with this motion? 14:43:16 I am okay with it 14:43:24 mlavalle: sure, and i will remove the -W 14:43:40 * mlavalle approving int he RFE 14:45:41 kailun: thank you very much for your proposal and code. Very much appreciated! 14:46:36 mlavalle: sure, my pleasure :) 14:46:59 Next one is https://bugs.launchpad.net/neutron/+bug/1774463 14:46:59 Launchpad bug 1774463 in neutron "RFE: Add support for IPv6 on DVR Routers for the Fast-path exit " [Wishlist,Triaged] 14:51:52 I am ok with this RFE 14:51:58 what do others think? 14:52:11 i'm ok too 14:52:14 makes sense to me 14:52:28 does it mean "RA" is responded by a compute node? 14:52:47 mlavalle: i am fine, just isn't a lot of info on the "how" 14:53:15 generally makes sense to me (if my understanding is right) though I would like ot know how it can be achieved. 14:54:00 i can see how on egress IPv6 could be send directly, but ingress is harder (rfe is for exit) 14:54:29 I think a case of prefix delegation also need to be considered. 14:54:45 we can ask clarifying questions from the author 14:55:02 direct him to this conversation and ask him to clarify 14:55:22 can we cover this in the l3 meeting? 14:55:43 Swami usually attends the L3 meeting 14:55:52 and we can certainly cover it there 14:55:57 yes, that might make sense 14:56:04 I have to say that he is on vacation the next two weeks 14:56:52 so yes, let's discuss in the next L3 meetings that he attends 14:57:04 i'll add some questions to the bug too 14:57:19 haleyb: thanks! 14:57:36 ok, I think we ran out of time 14:57:43 Thanks for attending! 14:57:52 #endmeeting