14:00:54 <mlavalle> #startmeeting neutron_drivers
14:00:55 <openstack> Meeting started Fri Dec 14 14:00:54 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:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:58 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:16 <haleyb> hi
14:01:16 <slaweq> hi o/
14:01:22 <mlavalle> o/
14:01:51 <haleyb> mlavalle: i have a hard stop today in :30 or so
14:01:55 <mlavalle> let's give a couple of minutes to others to join in
14:01:58 <mlavalle> haleyb: ack
14:02:40 <slaweq> amotoki and yamamoto wrote today that they will be not available on meeting
14:03:41 <mlavalle> oh yeah, I just saw the email chain in my inbox
14:03:48 <mlavalle> so let's get going
14:03:59 <mlavalle> #topic RFEs
14:05:01 <mlavalle> First up for today is https://bugs.launchpad.net/neutron/+bug/1796925
14:05:03 <openstack> Launchpad bug 1796925 in neutron "[RFE] port forwarding floating IP QoS" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:05:28 <mlavalle> We has previously discussed this one
14:05:44 <mlavalle> and we requested clarifications
14:08:52 <slaweq> for me this rfe sounds reasonable
14:09:20 <mlavalle> I am also +1
14:09:23 <slaweq> we should add some API extension to make it discoverable and document it carefully to explain how it works
14:09:29 <slaweq> but it's fine for me
14:09:34 <haleyb> +1
14:10:07 <mlavalle> mhhhh, let me clarify slaweq's comment
14:10:33 * mlavalle is always in principle against adding to our extensions sprawl
14:11:15 <mlavalle> do we really need an extension? should it have been this way since the beginning with port forwardings?
14:11:44 <mlavalle> I agree on the extensive documentation, including a release note
14:11:57 <slaweq> IMO it's new feature for port forwarding, no?
14:12:52 <slaweq> ok
14:12:53 <mlavalle> the way I see it, QoS for floating ips is already in place
14:13:09 <slaweq> if qos policy will be added to floating ip and not to: https://developer.openstack.org/api-ref/network/v2/?expanded=create-port-forwarding-detail#create-port-forwarding
14:14:02 <mlavalle> we just forgot to enforce it when the FIP is used for port forwarding, right?
14:14:07 <slaweq> *not to body of this request, than it may be without api extension - but I'm not sure how it works now if I will try to associate qos policy to such FIP - will it raise error? or will it be accepted?
14:16:35 <mlavalle> here's what I propose.... I will respond to the RFE indicting that we approve it as long as it only involves associating QoS policies to FIPs being used for port forwarding
14:16:52 <slaweq> +1
14:16:58 <mlavalle> any other change will require more discussion
14:17:11 <mlavalle> and I will also indicate the need for good documentation
14:17:32 <slaweq> I agree
14:17:55 <mlavalle> you were right in pointing out the difference slaweq :-)
14:18:09 <mlavalle> it was clarifying
14:18:23 <mlavalle> does this work for you haleyb ?
14:18:26 <slaweq> thx :)
14:18:39 <haleyb> yes, works for me
14:18:56 <mlavalle> ok, for the sake of time, I'll leave those notes later
14:19:32 <mlavalle> Next up is https://bugs.launchpad.net/neutron/+bug/1804634
14:19:34 <openstack> Launchpad bug 1804634 in neutron "[RFE] l3_agent should separate router_info creation logic" [Wishlist,In progress] - Assigned to Yang Youseok (ileixe)
14:20:05 <mlavalle> for this one, there are already patches, and haleyb indicated in them that RFE has to be approved first
14:20:58 <haleyb> yes, there are patches for both neutron and neutron-lib
14:21:51 <slaweq> I think that this should have specs which will be later also kind of documentation
14:22:18 <mlavalle> this sounds like a step forward from what Carl Baldwin and I did about 3 years ago
14:22:19 <slaweq> as IIUC some 3rd party projects may be impacted with those changes too
14:22:42 <mlavalle> but the submitter is taking more of an external view
14:23:23 <mlavalle> I think Carl and I were biased with our reference point of view
14:24:01 <mlavalle> so I think it is an interesting proposal, as long as we have a spec, as slaweq indicates
14:25:33 <haleyb> yes, i agree it is useful, but needs more documentation since it seems the intent is for out of tree users to extend things
14:26:05 <mlavalle> ok, let's move ahead with it, asking for a spec, does this works for everybody?
14:26:08 <haleyb> mlavalle: it will impact the intel router_info work of course...
14:26:15 <mlavalle> haleyb: yeap
14:26:56 <mlavalle> so let's give the wider community a chance to weigh in through the spec
14:27:08 <mlavalle> agree?
14:27:12 <slaweq> +1
14:27:31 <haleyb> +1
14:27:39 <mlavalle> ok, before we go
14:27:50 <mlavalle> before haleyb goes....
14:28:16 <mlavalle> 1) are you guys going to be around next Friday for this meeting? It will be the 21st?
14:28:31 <slaweq> I will be here
14:28:40 <slaweq> it will be my last day at work before Christmass
14:29:29 <mlavalle> so I will assume our Japanese friends will also be around, so we are having meeting then
14:29:38 <mlavalle> 2) https://bugs.launchpad.net/neutron/+bug/1795212
14:29:39 <openstack> Launchpad bug 1795212 in neutron "[RFE] Prevent DHCP agent from processing stale RPC messages when restarting up" [Wishlist,In progress] - Assigned to Kailun Qin (kailun.qin)
14:30:13 <mlavalle> we requested clarification in this RFE^^^^ and the submitter has responded
14:30:27 <mlavalle> so please take a look at his responses
14:30:34 <mlavalle> leave comments if necessary
14:30:47 <mlavalle> and we can pick it up as the first item in the agenda next week
14:30:57 <mlavalle> does that work?
14:31:06 <slaweq> ok, I will read it
14:31:42 <mlavalle> and with that, haleyb is free to go
14:32:26 <mlavalle> I think he left already
14:32:37 <mlavalle> have a great weekend!
14:33:00 <slaweq> have a good weekend then :)
14:33:09 <mlavalle> #endmeeting