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