14:00:18 <mlavalle> #startmeeting neutron_drivers
14:00:19 <openstack> Meeting started Fri Nov  2 14:00:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:32 <yamamoto> hi
14:00:43 <ralonsoh> hi
14:00:45 <slaweq> hi
14:00:47 <hle21> hi
14:01:13 <njohnston> hi
14:01:40 <mlavalle> let's hold 1 minute for others to join
14:02:46 <mlavalle> #topic Announcements
14:03:20 <mlavalle> Next week I will be travelling to the Berlin Summit and I don't know whether I will be able to facilitate this meeting or not
14:03:43 <mlavalle> In two weeks, I know I won't be able to attend because I will be flying back
14:04:02 <mlavalle> slaweq: would you run the meeting next week?
14:04:11 <slaweq> mlavalle: sure, I can
14:04:23 <mlavalle> how about the weekk after?
14:04:37 <slaweq> if we will have quorum
14:04:42 <mlavalle> ok
14:04:47 <slaweq> I can run it both weeks
14:04:50 <slaweq> that's fine for me
14:04:50 <mlavalle> we can work together in the agenda
14:04:56 <slaweq> sure
14:04:59 <slaweq> thx
14:05:01 <mlavalle> Thanks!
14:05:36 <mlavalle> For those in the US, please remember that starting next week, this meeting will be one earlier in your local time
14:05:45 <mlavalle> we are falling back to Standard Time
14:06:09 <mlavalle> Let's move on
14:06:14 <mlavalle> #topic RFEs
14:07:09 <mlavalle> Last week liuyulong_ I think wanted to discuss this when we hit the end of the meeting: https://bugs.launchpad.net/neutron/+bug/1796824
14:07:09 <openstack> Launchpad bug 1796824 in neutron "Port in some type of device_owner should not allow update IP address" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:07:18 <mlavalle> so let's start here
14:07:26 <hle21> mlavalle: i would like community help to review 2 issues for any solutions later
14:08:09 <hle21> https://bugs.launchpad.net/neutron/+bug/1800599
14:08:10 <openstack> Launchpad bug 1800599 in neutron "[RFE]Neutron API server: unexpected behavior with multiple long live clients" [Undecided,New]
14:08:22 <liuyulong_> Let's quota something from the LP bug: Some L3 ports can now be directly modify the IP address, but there are some type of device_owner, for instance network:router_centralized_snat, should not allow to change the IP address, otherwise it will make things really complicated.
14:08:44 <liuyulong_> Why it is complicated, it's because the L3 agent side does not handle the 'network:router_centralized_snat' port IP change for dvr router. If try to allow the IP change for these type of ports, seems we need a lot of work to do, such as change the qr- or sg- device IP address, change the iptables rules, change the route rules etc. And IMO, such IP change for these port is not so much useful, and even it is sometimes not visible to the
14:08:44 <liuyulong_> normal user.
14:09:55 <mlavalle> hle21: that RFE hasn't been triaged yet. I will go through it today and give my feedback. Please don't expect us to discuss it in this meeting, unless we have time left at the end
14:10:19 <hle21> mlavalle: sure, thanks!
14:11:21 <mlavalle> liuyulong_: right now, if we change those IP addresses, nothing really happens in the data plane, right?
14:12:11 <liuyulong_> Yes, but except router public gateway port.
14:12:37 <liuyulong_> network:ha_router_replicated_interface
14:12:37 <liuyulong_> network:router_centralized_snat
14:12:37 <liuyulong_> network:router_ha_interface
14:12:37 <liuyulong_> network:router_interface
14:12:37 <liuyulong_> network:router_interface_distributed
14:13:07 <liuyulong_> These router related port types have nothing happens in L3 agent side.
14:13:16 <mlavalle> liuyulong_: so the proposed change wouldn't disallow changing the ip address for public gateway port, right?
14:13:49 <liuyulong_> Yes, network:router_gateway will still be allowed.
14:15:22 <haleyb> sorry i'm late
14:15:47 <mlavalle> I don't think there are many users out there changing the IP address of these port owners. Otherwise, we would have already heard from them
14:16:27 <slaweq> I agree mlavalle but still I think that change this and give user proper feedback on API level will be good
14:16:47 <mlavalle> having said that, as long as the change is discoverable, it doesn seem to hurt
14:17:06 <slaweq> +1
14:17:14 <liuyulong_> Yes, but it can change now. We should disallow it as early as possile.
14:17:18 <mlavalle> not executing an action silently is not a correct thing, as slaweq points out
14:19:05 <mlavalle> what do others think?
14:19:23 <liuyulong_> And it has some bad side effect, such as IP multipoint installation
14:20:15 <liuyulong_> Device IP never changed in L3 agent side, but neutron DB think it is free, then a new port uses it.
14:20:38 <mlavalle> that's true
14:20:58 <haleyb> i think it's fine.  if at some point someone wants to do all the hard, complicated work they can
14:21:42 <mlavalle> yeah, if we find the use case for it, then we can do the hard work
14:22:04 <slaweq> I agree
14:22:19 <liuyulong_> Yep, the current implementation has a easy way to override it.
14:22:31 <liuyulong_> Thanks to Manjeet Singh Bhatia
14:22:33 <mlavalle> any concerns to approve this?
14:23:21 <liuyulong_> The neutron built-in l3 plugin supply the port types: https://review.openstack.org/#/c/608909/15/neutron/services/l3_router/l3_router_plugin.py
14:23:47 <liuyulong_> Any subprojects and easily override it.
14:24:01 <liuyulong_> Any subprojects can easily override it
14:24:24 <yamamoto> how?
14:25:22 <liuyulong_> Just do not use the built-in l3 plugin or override the port type list there, yamamoto
14:25:55 <hongbin> but using the same api extension?
14:26:51 <yamamoto> liuyulong_: it would work for monolithic plugins but not for drivers like https://github.com/openstack/networking-odl/blob/master/networking_odl/l3/l3_flavor.py
14:27:08 <hongbin> or if the port type list is override, it should present a different api extension?
14:28:06 <liuyulong_> yamamoto, such project will not meet these port types, right?
14:28:24 <yamamoto> what do you mean by "meet"?
14:29:15 <liuyulong_> I'm not familar to network_odl, will it have some port type related to DVR? for instance, network:router_centralized_snat?
14:30:52 <yamamoto> i guess dvr specific ones are ok. but your list includes network:router_interface
14:31:12 <liuyulong_> hongbin, this is about update port IP, it's L2 API, but port belongs to L3, and L3 do not want change the IP. So extension seems not so much needed.
14:32:36 <hongbin> i see there is an extension 'L3_port_ip_change_not_allowed'
14:32:50 <liuyulong_> yamamoto, OK, that can be removed from the list, please leave a comment here: https://review.openstack.org/#/c/608909/15/neutron/services/l3_router/l3_router_plugin.py
14:33:43 <hongbin> however, i heard that other plugin can override the port type list but still using this extension?
14:33:49 <liuyulong_> hongbin, slaweq suggests me to add a shim extension to notify user that there some L3 behavior change.
14:34:11 <hongbin> liuyulong_: ack
14:35:03 <slaweq> I just wanted to make this new behaviour to be discoverable
14:35:15 <mlavalle> yeah, that is important
14:35:23 <liuyulong_> slaweq, agree, thanks
14:36:01 <hongbin> yes, then if other plugin can override what kind of port should be disallowed to change ip address, but present the same api extension, this behavior is still discoveralble?
14:36:55 <liuyulong_> hongbin, yes, it is.
14:37:51 <mlavalle> it probably is, as long as that plugin documents properly the list of ports
14:38:03 <hongbin> ok
14:38:08 <mlavalle> and BTW, if we implement this, we should do the same
14:38:26 <liuyulong_> The IP change detection code is right now code directly to the L2 IPAM.
14:38:57 <liuyulong_> OK, DOC work added to my list.
14:39:44 <mlavalle> That would include a section in devref, indicating how other plugins can override the list
14:40:04 <hongbin> mlavalle: i think the extension itself is the best place to document the list of port types it is going to support, but push it down to the plugin is also fine with me
14:40:53 <mlavalle> hongbin: you make a good point. we can disucss this detail in gerrit. as long as it is properly documented
14:41:08 <mlavalle> yamamoto: are you ok now with this?
14:41:11 <hongbin> mlavalle: ack
14:41:43 <liuyulong_> hongbin, good point, but like I said in the patch inline comments, it is an requirement from L3 to L2: we do not want these port change IP, we can give the port types.
14:42:14 <hongbin> liuyulong_: ok
14:42:28 <yamamoto> as far as its scope is only device_owner types which are specific to the reference implementation, i'm ok with it
14:42:51 <mlavalle> any other concerns?
14:43:40 <mlavalle> ok, we'll approve this
14:44:00 <mlavalle> yamamoto: I'll include your latest remark in the approval comment in the RFE
14:44:14 <yamamoto> mlavalle: thank you
14:45:21 <liuyulong_> Many thanks to everyone.
14:46:45 <mlavalle> liuyulong_: thanks for your submission
14:46:55 <mlavalle> yamamoto: https://bugs.launchpad.net/neutron/+bug/1796824/comments/9
14:46:55 <openstack> Launchpad bug 1796824 in neutron "Port in some type of device_owner should not allow update IP address" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:47:19 <yamamoto> liuyulong_: FYI, at least midonet allows updates of ips on router_interface ports. i don't think it's well tested though. :-)
14:47:32 <mlavalle> LOL
14:47:46 <yamamoto> mlavalle: looks fine
14:47:54 <liuyulong_> yamamoto, thanks, I'll do some code search.
14:48:57 <mlavalle> liuyulong_: I have another RFE in the agenda from you: https://bugs.launchpad.net/neutron/+bug/1796925
14:48:57 <openstack> Launchpad bug 1796925 in neutron "[RFE] port forwarding floating IP QoS" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:49:15 <mlavalle> we will probably not have time to discuss it today
14:49:22 <mlavalle> can we move it to next week?
14:49:33 <liuyulong_> OK, I'm fine with it.
14:49:45 <mlavalle> cool, thanks :-)
14:50:01 <mlavalle> so let's move one
14:50:12 <mlavalle> #topic On demand agenda
14:50:44 <mlavalle> ralonsoh brings up this question:
14:51:15 <mlavalle> Should we add a new extension just to modify an integer parameter validation? Reduce the port range from 0-64K to 1-64K. This change is trivial and both APIs (new/old) can coexist without any clash. Review: https://review.openstack.org/#/c/613562/
14:52:12 <ralonsoh> liuyulong_, you are just changing the validation of this parameter, reducing the valid range
14:52:13 <hongbin> i would vote for no
14:52:26 <mlavalle> at first glance, from a pragmatical point of view, I agree with ralonsoh
14:52:26 <ralonsoh> we have plenty of extensions, too many
14:52:37 <mlavalle> yes
14:52:39 <liuyulong_> Yes, I just do not want it too, since patch set 1 is done it in the simple way
14:52:55 <njohnston> +1
14:53:06 <liuyulong_> But how to apply this change to the master neutron is the main problem, since neutron does not use the neutron-lib master branch yet.
14:53:07 <liuyulong_> So copy this changed extension file to neutron repo as a new temp work around? That is totally same to current change.
14:53:30 <liuyulong_> Quoted from the gerrit ^^^
14:53:34 <mlavalle> and from a pragmatical point of view, port forwarding is such a young feature, that I don't think we are going to affect many users out there
14:53:35 <slaweq> I agree that it may be a bit too much but from the other side, it's API change - if user now created PF with port=0 and it was fine from API PoV, then it will not raise exception
14:54:06 <slaweq> *now raise exception
14:54:16 <njohnston> possibility for an upgrade check, slaweq?
14:54:24 <mlavalle> strictly speaking, that's true
14:54:39 <yamamoto> what's the current behaviour for port=0?
14:54:40 <slaweq> njohnston: it's not related to upgrade check IMO
14:54:53 <mlavalle> but how many users are there in this situation, reallistically, since we released this a copuple of months ago
14:54:59 <slaweq> upgrade check is tool for operators, and this is user's API change
14:55:16 <liuyulong_> https://review.openstack.org/#/c/613562/1/neutron_lib/api/definitions/floating_ip_port_forwarding.py this simple change is also my favorite, : )
14:55:25 <hongbin> slaweq:  if passing port=0 is considered a bug, then raise an exception is ok becuase it is not considered as api change
14:56:03 <mlavalle> hongbin: right, I think that is the correct way to see the issue
14:56:06 <liuyulong_> hongbin, yes, for now it is 500 error to user
14:56:10 <mlavalle> as a bug that we are now fixing
14:56:46 <slaweq> if it raises exception (500 for example) now then it's IMO perfectly fine to fix it without new extension
14:56:59 <slaweq> I thought that it's now returning 200 OK instead
14:57:16 <mlavalle> and let's include a fixes section in the release notes
14:57:29 <mlavalle> documenting the change
14:57:42 <mlavalle> we all agree?
14:57:45 <ralonsoh> +1
14:57:47 <yamamoto> +1
14:57:48 <hongbin> +1
14:57:51 <slaweq> +1
14:57:53 <njohnston> +1
14:58:12 <haleyb> +1
14:58:13 <mlavalle> ok, cool for the overwhelming consensus.... LOL
14:58:26 <slaweq> +2 :)
14:58:27 <mlavalle> ralonsoh: thanks for bringing this up
14:58:30 <ralonsoh> np
14:59:01 <mlavalle> The next one I will leave for next meeting, ok slaweq ?
14:59:07 <slaweq> sure
14:59:15 <mlavalle> Thanks everybody
14:59:19 <slaweq> thx
14:59:21 <ralonsoh> bye!
14:59:22 <slaweq> o/
14:59:27 <slaweq> have a great weekend :)
14:59:27 <mlavalle> believe or not, I will miss you the next two weeks
14:59:48 <njohnston> safe travels, all those bound for Berlin!
14:59:49 <mlavalle> each one of you: slaweq, haleyb, yamamoto, njohnston, ralonsoh, liuyulong_ :-)
15:00:03 <mlavalle> #endmeeting