15:06:33 <haleyb> #startmeeting neutron_l3
15:06:34 <openstack> Meeting started Thu Jan  3 15:06:33 2019 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:06:40 <openstack> The meeting name has been set to 'neutron_l3'
15:07:34 <haleyb> #topic Bugs
15:08:17 <haleyb> There was a new bug filed yesterday regarding IPAM, which is on the l3 spectrum
15:08:31 <haleyb> https://bugs.launchpad.net/neutron/+bug/1810314
15:08:32 <openstack> Launchpad bug 1810314 in neutron "neutron objects base get_values() fails with KeyError" [Critical,New]
15:08:44 <haleyb> falls between IPAM and DB
15:09:02 <slaweq> IMO it's failing because of switch to Subnet OVO in IPAM module
15:09:19 <slaweq> and (probably) fix should be somewhere on tricircle's side
15:09:20 <haleyb> slaweq: right, and i didn't know if a quick fix was good or bad
15:09:33 <slaweq> what quick fix?
15:09:36 <slaweq> revert?
15:09:59 <haleyb> slaweq: i think we can tweak get_values() to not fail, but maybe more of a hack
15:10:19 <haleyb> return [c[0] for c in query]
15:10:21 <slaweq> ahh, yes it would be hack IMO
15:10:34 <haleyb> that fails because apparently query = [{}]
15:10:46 <slaweq> I would prefer firts that some OVO expert would take a look at it
15:11:00 <slaweq> njohnston ^^ :)
15:11:10 <njohnston> Yes, let me take a look
15:11:33 <slaweq> haleyb: but if You will change this get_values() function, I think that this test will fail later as this subnet should be created and it wasn't, right?
15:11:33 <njohnston> I'm familiar with that OVO change
15:11:34 <haleyb> slaweq: ack, the quick hack of something like return [c[0] for c in query if c] would fix it, but seemed dirty
15:12:05 <haleyb> having njohnston look would be better than a hack :)
15:12:18 <njohnston> yep, I'll look at it today
15:12:21 <slaweq> +1
15:12:25 <slaweq> thx njohnston
15:13:05 <njohnston> happy to help!
15:13:10 <haleyb> great, thanks njohnston !
15:13:48 <haleyb> https://bugs.launchpad.net/neutron/+bug/1809134
15:13:49 <openstack> Launchpad bug 1809134 in neutron "TypeError in QoS gateway_ip code in l3-agent logs" [High,In progress] - Assigned to Brian Haley (brian-haley)
15:14:01 <haleyb> https://review.openstack.org/#/c/626401/ in progress
15:14:29 <haleyb> i need to address review comments again, but obvious but
15:14:32 <haleyb> s/bug
15:15:44 <slaweq> but I see that even with this patch still many tests in neutron-tempest-plugin-dvr-multinode-scenario are failing :/
15:16:06 <slaweq> so this wasn't real issue which cause those failures?
15:17:04 <haleyb> i think it fixed some other failures, but not all of them
15:17:14 <slaweq> ok
15:17:27 <slaweq> so we will have to investigate others later :)
15:17:37 <slaweq> I will keep it in mind
15:18:24 <haleyb> yes, i think a lot of the rest were timeout failures
15:19:45 <haleyb> next bug is https://bugs.launchpad.net/neutron/+bug/1810349
15:19:46 <openstack> Launchpad bug 1810349 in neutron "agent gw ports created on non dvr destination hosts" [Medium,In progress] - Assigned to Enyinna Ochulor (enyinna1234)
15:20:02 <haleyb> https://review.openstack.org/#/c/628071/ was just proposed, have not looked yet
15:22:03 <haleyb> next is https://bugs.launchpad.net/neutron/+bug/1774459
15:22:04 <openstack> Launchpad bug 1774459 in neutron "Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,Confirmed] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:22:37 <haleyb> i was able to get through review yesterday, and Swami has continued work with a follow-on as well.
15:23:14 <haleyb> he's not here today...
15:24:24 <haleyb> https://bugs.launchpad.net/neutron/+bug/1806770
15:24:25 <openstack> Launchpad bug 1806770 in neutron "DHCP Agent should not release DHCP lease when client ID is not set on port" [Medium,In progress] - Assigned to Arjun Baindur (abaindur)
15:24:55 <haleyb> there is a review, but i don't see an update for a while, https://review.openstack.org/#/c/623066/
15:25:45 <haleyb> next is https://bugs.launchpad.net/neutron/+bug/1798475
15:25:46 <openstack> Launchpad bug 1798475 in neutron "Fullstack test test_ha_router_restart_agents_no_packet_lost failing" [High,In progress] - Assigned to LIU Yulong (dragon889)
15:26:51 <haleyb> liu is still investigating
15:27:35 <haleyb> that's the only bugs i have
15:27:46 <haleyb> #topic Open discussion
15:27:55 <haleyb> anything else to discuss?
15:27:58 <slaweq> I have one bug also to mention
15:27:59 <slaweq> https://bugs.launchpad.net/neutron/+bug/1809238
15:28:00 <openstack> Launchpad bug 1809238 in neutron "[l3] `port_forwarding` cannot be set before l3 `router` in service_plugins" [High,In progress] - Assigned to LIU Yulong (dragon889)
15:28:06 <slaweq> it's somehow related to L3
15:28:24 <slaweq> as it is related to port forwarding service plugins
15:28:53 <slaweq> it looks that portforwarding service plugin require to be loaded in proper order, after L3 service plugin
15:29:32 <slaweq> so I want to ask You to check this and tell there what You think about it - should we just document properly that order of service plugins in config file is important
15:30:02 <slaweq> or should we implement some internal mechanism to load plugins in proper order
15:30:29 <haleyb> right, i looked yesterday and was surprised order was that important.
15:31:21 <slaweq> there is patch for that: https://review.openstack.org/626561
15:31:23 <haleyb> slaweq: so have a known good order and load if specified?
15:32:00 <slaweq> yes, I was thinking about something like priorities for plugins defined somewhere internally
15:32:25 <slaweq> and then check which of them are configured and sort them in proper order
15:32:28 <slaweq> if we need some
15:32:53 <slaweq> IMHO raising exception which is proposed now in https://review.openstack.org/626561 is not most user friendly solution
15:33:07 <slaweq> but I just wanted to ask others to take a look at it :)
15:33:52 <haleyb> that would be best imo.  in this case should the exception still be raised if the l3 plugin wasn't specified at all?
15:34:11 <slaweq> IMHO yes
15:34:30 <slaweq> in such case we should raise exception to tell operator that his config is wrong
15:35:18 <haleyb> we just don't know the reason (wrong order possibly), but we can document that until we have something better
15:35:58 <slaweq> yes, that is kind of workaround for now IMHO
15:37:23 <haleyb> i think i like that better, just wonder how we'd make the internal list withoug making it too complicated
15:38:31 <haleyb> but maybe that's work for whoever codes it up :)
15:38:38 <slaweq> +1
15:39:21 <haleyb> i.e. we don't need to list everything, just a small subset
15:40:22 <slaweq> yes, I think so - we can just list plugins which should be loaded "before" or "after" something else
15:40:33 <slaweq> and left all others as default
15:41:07 <haleyb> right.  let's just add a comment for liu
15:41:09 <slaweq> but that some kind of idea - I don't think it will be complicated to code but I may be wrong
15:41:15 <slaweq> ok, thx haleyb
15:41:37 <haleyb> we can make it complicated, but shouldn't :)
15:41:45 <slaweq> LOL
15:41:51 <njohnston> :-)
15:42:16 <haleyb> any other things to discuss?
15:42:31 <slaweq> not from me
15:42:38 <njohnston> nope
15:43:47 <haleyb> #endmeeting