14:00:22 <mlavalle> #startmeeting neutron_drivers
14:00:23 <openstack> Meeting started Fri Jun  8 14:00:22 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:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:32 <mlavalle> Hi there!
14:00:33 <manjeets_> hello
14:00:34 <yamamoto> hi
14:00:54 <mlavalle> Good evening yamamoto
14:01:04 <mlavalle> Good morning manjeets_
14:01:39 <haleyb> hi
14:01:40 <manjeets_> happy friday mlavalle
14:03:13 <mlavalle> Before starting, I just want to make sure yamamoto has seen this: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131252.html
14:03:40 <mlavalle> I checked the Midonet repo and didn't seem to me there was going to be impact
14:03:54 <mlavalle> But I would like you to double check
14:04:06 <yamamoto> i haven't noticed it. i'll check later.
14:04:15 <mlavalle> yamamoto: Thanks!
14:04:21 <amotoki> hi, sorry for late.
14:04:42 <amotoki> today is a holiday special to my comany and I had some beer.... so my response might be a bit slow
14:05:03 <mlavalle> amotoki: welcome, you haven't lost anything
14:05:18 <mlavalle> #topic RFEs
14:05:19 <haleyb> mmm, beer :)  to bad it's only 10am here
14:05:32 <mlavalle> LOL
14:05:35 <amotoki> :)
14:05:38 <manjeets_> 7 am here :( imagine how bad it is here
14:06:10 <mlavalle> First RFE to discuss today is https://bugs.launchpad.net/neutron/+bug/1744223
14:06:11 <openstack> Launchpad bug 1744223 in neutron "[RFE] VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations" [Wishlist,Confirmed] - Assigned to Hunt Xu (huntxu)
14:07:17 <mlavalle> We discussed this RFE 3 weeks ago. We were close to approve it, contingent on one question
14:07:33 <mlavalle> The submitter has not responded so far
14:08:07 <mlavalle> I propose marking it postponed and let him / her change the status if there is still interest in pursuing it
14:10:23 <yamamoto> can he change the status by himself?
14:10:23 <amotoki> In my understanding the problem is to sync external IPs with a router operation. right?
14:12:32 <amotoki> yamamoto: what do you mean?
14:13:12 <yamamoto> my understanding is that he wants to allow changing v6 address when there are only v4 connections. and vice versa.
14:13:18 <mlavalle> yamamoto: I just propose to change the tag. If he was able to file the bug, he should be able to change the tag
14:13:54 <yamamoto> amotoki: i was concerning if he can change tags
14:14:01 <yamamoto> mlavalle: ok then sounds fine
14:15:01 <mlavalle> and yes, I share yamamoto's understanding of the request
14:15:27 * mlavalle changing the tag and leaving a comment
14:18:12 <mlavalle> Done
14:18:40 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1757044
14:18:41 <openstack> Launchpad bug 1757044 in neutron "[RFE] neutron L3 router gateway IP QoS" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:19:07 <mlavalle> There are two patches up for review for this:
14:19:25 <mlavalle> https://review.openstack.org/#/c/424468/
14:19:40 <mlavalle> https://review.openstack.org/#/c/568526/
14:20:56 <amotoki> theoretically we can apply QoS policy to a router gateway already by applying QoS policy to a gateway port
14:21:26 <mlavalle> correct
14:21:28 <amotoki> but I agree that it would be nice if we have a way via router gateway in the neutron API.
14:21:49 <mlavalle> but he makes the observation that approach is to broad
14:23:20 <amotoki> so iwhat is expected by applying qos-policy-id to a router gateway?
14:24:43 <amotoki> actually I am confused with the problem statement. "When QoS is bound to the gateway port, all north-south traffic is restricted. Such restriction is inflexible" and "Therefore, we need to provide an alternative method in the view of L3. Aka, allowing bind QoS to router gateway IP."
14:25:08 <yamamoto> i'm not sure what kind of traffic it's expected to apply
14:25:23 <yamamoto> only snat'ed traffic?
14:25:34 <yamamoto> or any traffic using the ip?
14:25:45 <amotoki> is he suggesting to apply QoS for SNAT traffic?
14:26:02 <mlavalle> snat was my interpretation
14:26:20 <amotoki> does this RFE request to apply QoS to traffic via gateway port only with gateway IP (not FIP) ?
14:26:29 <amotoki> ah, i see.
14:27:48 <yamamoto> i thought he meant snat. but there can be other traffic using the address. eg. vpnaas
14:28:05 <mlavalle> tthat's a good point
14:28:35 <amotoki> good point
14:29:54 <mlavalle> thinking about it, he also meant vpnaas traffic
14:29:58 <mlavalle> maybe
14:30:35 <mlavalle> I propose asking clarification as to the use case he has in mind
14:32:18 <mlavalle> ok, leaving clarification question in the RFE
14:32:42 <yamamoto> i wonder if something to specify on port can be more flexible. e.g "this qos policy on port applies only traffic with ips on this port itself"
14:36:15 <mlavalle> ok, left follow up questions in the RFE
14:37:06 <mlavalle> Our next RFE today is https://bugs.launchpad.net/neutron/+bug/1774459
14:37:07 <openstack> Launchpad bug 1774459 in neutron "RFE: Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [Wishlist,New]
14:37:30 <mlavalle> It is more a request for guidance as to how to tackle a problem in DVR
14:38:31 <haleyb> right, it's a bug that needs solving
14:41:52 <haleyb> i guess i'm not a fan of running something that is watching packets
14:42:21 <mlavalle> me neither
14:42:54 <haleyb> maybe it's possible to have something running that monitors the ARP table periodically?
14:43:52 <haleyb> ip monitor neigh (for example)
14:45:24 <mlavalle> how about adding these potential solutions to the RFE and see if we can iterate to a solution?
14:45:49 <haleyb> sure, because we already have an IPMonitor class
14:46:24 <haleyb> the keepalived state change code uses it
14:47:34 <haleyb> i'll but a commen in the bug
14:48:18 <amotoki> is this an issue with DVR and L3-HA or only with DVR?
14:48:31 <amotoki> (sorry I haven't understood the whole problem scope.)
14:48:51 <mlavalle> it's L3-HA
14:49:46 <mlavalle> haleyb: is this what you are talking about: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_monitor.py#L59?
14:49:54 <amotoki> thanks. I am trying to trace what is happening...
14:50:43 <haleyb> mlavalle: yeah, it runs in the l3-ha case and watches for events
14:53:43 <mlavalle> ok, added another comment pointing to the piece of code
14:54:12 <mlavalle> let's see if we can get the 'brainstorming' going
14:54:27 <mlavalle> any other suggestions from the team?
14:54:50 <yamamoto> nothing from me
14:54:58 <amotoki> me neither
14:55:01 <haleyb> join amotoki for a beer?
14:55:07 <yamamoto> good idea
14:55:22 * haleyb can't help himself from joking
14:55:36 <manjeets__> :)
14:55:39 * mlavalle has a dentist appointment i 2 hours
14:55:40 <amotoki> :)
14:55:42 <haleyb> mlavalle: i did have one comment
14:55:52 <mlavalle> shoot
14:56:21 <haleyb> and maybe it's just because i haven't followed the flow of rfe -> blueprint, etc
14:56:53 <haleyb> in a spec we had a specific testing section, but we don't seem to specifically have one for an rfe
14:57:51 <haleyb> someone here noticed that it would be good to know what type of testing was proposed so we could say "you need fullstack too" for example
14:57:53 <amotoki> RFEs request what we need to have rather than how it can be implemented.
14:58:31 <amotoki> if usecase or request is reasonbale but it needs more discussion on how to achieve/implement it, we usually discuss them in specs.
14:58:42 <mlavalle> correct
14:59:16 <mlavalle> there are RFEs that are simple enough that don't require spec, so we can proceed to implement
14:59:32 <mlavalle> But in more complex cases, once we agree on the what, we need a spec
15:00:04 <mlavalle> running out of time
15:00:09 <mlavalle> #endmeeting