14:02:07 <slaweq> #startmeeting neutron_drivers
14:02:08 <openstack> Meeting started Fri Dec 13 14:02:07 2019 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:08 <slaweq> hi
14:02:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:12 <openstack> The meeting name has been set to 'neutron_drivers'
14:02:13 <yamamoto> hi
14:02:28 <slaweq> sorry for being a bit late
14:02:40 <mlavalle> o/
14:02:55 <njohnston> o/
14:03:26 <slaweq> lets wait a bit for haleyb and amotoki
14:03:42 <yamamoto> i can't attend next three weeks
14:04:17 <slaweq> yamamoto: I think that this week may be our last meeting in this year
14:04:27 <slaweq> as I will also not be able to attend next week probably
14:04:38 <slaweq> and later I'm on PTO until 7th of January
14:04:51 <slaweq> mlavalle: how it's for You?
14:05:28 <mlavalle> That's fine with me
14:06:05 <slaweq> ok, so I think we have first agreement today :)
14:06:44 <njohnston> so the next meeting will be... January 10th?
14:06:49 <slaweq> I will send email about it later
14:07:04 <njohnston> +1
14:07:06 <slaweq> njohnston: it seems so, yes
14:07:21 <slaweq> ok, lets start than, we have quorum already
14:07:30 <slaweq> and we have couple of RFEs to discuss
14:07:42 <slaweq> #topic RFEs
14:08:04 <slaweq> first one is one which we started last week
14:08:07 <slaweq> https://bugs.launchpad.net/neutron/+bug/1851609
14:08:07 <openstack> Launchpad bug 1851609 in neutron "Add an option for graceful l3 agent shutdown" [Medium,In progress] - Assigned to Oleg Bondarev (obondarev)
14:08:58 <slaweq> beagles wrote a comment about how tripleo is doing that
14:11:06 <slaweq> AFAIU proposal is related to point 2) from beagles' comment
14:11:54 <slaweq> but I wonder if it would be possible to do it somehow automatically, without new config option
14:15:38 <amotoki> sorry for late. train to home was delayed...
14:16:45 <slaweq> amotoki: hi
14:17:25 <mlavalle> so the way I read beagles comment is that he agrees with Oleg that this is needed in Neutron
14:17:54 <njohnston> if it is possible to do a graceful shutdown, it is nearly always the preferable thing to do
14:18:06 <mlavalle> the point is to enable a clean failover
14:18:15 <mlavalle> in the HA case
14:19:52 <slaweq> but the problem is that users don't always need to stop e.g. keepalived processes
14:20:16 <slaweq> it's needed only in some cases, like e.g. when it works in kubernetes managed containers
14:20:27 <mlavalle> yeah, that is why the proposed option's default value is false
14:20:47 <mlavalle> https://review.opendev.org/#/c/693323/8/releasenotes/notes/l3_agent_graceful_shutdown-87bf3304e6fab8a5.yaml
14:21:43 <slaweq> yes, I know
14:22:26 <slaweq> but I was wondering if there is any way to e.g. automatically discover by L3 agent if graceful stop is needed or not
14:22:34 <slaweq> but probably there is no any way to do that
14:22:43 <slaweq> so config option would be the best solution
14:25:53 <slaweq> so I'm ok with this proposal
14:28:48 <mlavalle> yeah, seems to make sense
14:29:40 <amotoki> I read thru the discussion and RFE comments. it sounds reasonable. we cannot avoid downtime around graceful shutdown but it would be intentional.
14:30:28 <slaweq> yamamoto: any thoughts about it?
14:31:12 <yamamoto> i don't know how containerized l3 agent works
14:31:20 <yamamoto> does it use hostnetwork?
14:33:40 <mlavalle> http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/
14:34:27 <slaweq> yamamoto: actually I don't know but my understanding is that the problem is that kubernetes kills in non-graceful way keepalived processes (I'm not sure if those processes are in same pod as L3 agent or in separate ones)
14:34:39 <mlavalle> so yes, it can
14:37:07 <yamamoto> so this rfe is to introduce an option to make l3 agent shutdown its keepalived gracefully?
14:37:25 <slaweq> yamamoto: yes, that's how I understand it at least
14:38:33 <mlavalle> me too
14:38:34 <yamamoto> kubernetes somehow gives it a chance to clean up its children by itself?
14:38:36 <amotoki> my understanding is that this rfe deletes routers before l3-agt shuts down. when a router is deleted, keepalived is cleanup together.
14:39:49 <yamamoto> https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods
14:40:42 <yamamoto> shutdown keepalived gracefully in this 30s grace period?
14:40:42 <slaweq> amotoki: your understanding is good, see proposed patch https://review.opendev.org/#/c/693323/8/neutron/agent/l3/agent.py
14:42:48 <yamamoto> ok it makes sense to me
14:43:14 <amotoki> yamamoto: I think the proposal is to delete routers to clean up VIP usages rather than depending on keepalived aliveness, but I am not sure how they are shutdown...
14:44:36 <slaweq> so, just to make it clear: we are all good to approve this rfe and new config option, right?
14:44:38 <yamamoto> amotoki: i consider how to clean up is an implementation detail :-)
14:44:55 <amotoki> yamamoto: yeah :)
14:45:09 <amotoki> good to approve it
14:45:41 <mlavalle> I am good with it
14:45:45 <yamamoto> me too
14:46:05 <slaweq> ok, thx
14:46:10 <slaweq> I will approve it after the meeting
14:46:33 <slaweq> next one is old one
14:46:36 <slaweq> https://bugs.launchpad.net/neutron/+bug/1821208
14:46:37 <openstack> Launchpad bug 1821208 in neutron "[RFE] Only enforce policy when selected option does not match default" [Wishlist,Confirmed]
14:46:45 <slaweq> but I would like to maybe get back to it quickly
14:47:53 <njohnston> Ah yes, this old chestnut
14:48:46 <njohnston> What specifically did you want to talk about it, slaweq?
14:49:31 <slaweq> njohnston: I would like to revive this and either approve or abandon it
14:51:28 <amotoki> My understanding on the discussion so far are: (1) the original RFE was proposed to handle boolean field update with default values (2) I tried to expand it to all field types (3) I proposed to do it only for visible fields (as there seems no side effect) in #7 (4) slawek proposed a config option on the API behavior in #8
14:52:49 <slaweq> amotoki: yes, that's good summary
14:53:14 <amotoki> generally speaking, it is not recommended to determine the API behavior based on a config options as it is not discoverable from API users.
14:53:57 <slaweq> amotoki: makes sense, so this isn't option which we should choose
14:54:07 <njohnston> Three points: It is addressing an edge case that does not come up very often.  It has a clear workaround (don't specify the attribute in question so that it goes to the default value).  After consideration I am not sure if the value delivered is worth the work.
14:54:30 <slaweq> njohnston: so You are proposing to abandon this rfe, right?
14:54:35 <mlavalle> which was my original response to the RFE
14:54:56 <mlavalle> why do this for an edge case?
14:54:57 <njohnston> With limited developer bandwidth I think we have more pressing concerns
14:55:20 <amotoki> only value I see is that we can paste a response to PUT body.
14:55:37 <slaweq> njohnston: that's good option for me too :)
14:55:58 <slaweq> so based on njohnston's comment, I propose to abandon this rfe
14:56:06 <slaweq> are You fine with that?
14:56:10 <mlavalle> +1
14:56:14 <amotoki> +1
14:56:32 <yamamoto> njohnston: has the issue with horizon been solved since then?
14:56:42 <amotoki> IIRC this RFE starts from a bug in horizon. Although I am not sure the status of the horizon bug, it should be addressed there.
14:57:43 <njohnston> yes, I believe the horizon bug has been solved
14:57:49 * njohnston looks for the reference for that
14:58:42 <yamamoto> +1 for abandon then
14:58:56 <slaweq> thx
14:59:05 <amotoki> perhaps it comes from some bug in horizon policy support. it might be fixed. Otherwise we will receive a bug in horizon :)
14:59:13 <slaweq> I have 2 quick on demand items too
14:59:19 <slaweq> #topic On Demand agenda
14:59:42 <yamamoto> njohnston: paste the reference in the rfe if you find it
14:59:52 <njohnston> yamamoto: will do, thanks!
14:59:53 <slaweq> https://review.opendev.org/#/c/697076/ - please review it and tell there what do You think about having octavia-ovn-provider repo as new stadium project
15:00:05 <slaweq> and second one
15:00:07 <slaweq> I want to start discussion about neutron in devstack: http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011544.html
15:00:26 <slaweq> please read it and maybe You can reply to it if You have any thoughts about it
15:00:30 <slaweq> that's all from me
15:00:35 <slaweq> we are out of time already
15:01:19 <slaweq> so at the end I would like to thank all of You for great and productive year and wish You all the best for upcoming holiday season :)
15:01:31 <slaweq> and see You on next meeting in 2020
15:01:32 <mlavalle> same to you
15:01:33 <slaweq> o/
15:01:40 <slaweq> #endmeeting