15:00:49 <mlavalle> #startmeeting neutron_l3
15:00:50 <openstack> Meeting started Thu Mar 30 15:00:49 2017 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:54 <openstack> The meeting name has been set to 'neutron_l3'
15:00:56 <john-davidge> o/
15:01:01 <haleyb> hi
15:01:21 <mlavalle> welcome back john-davidge. how was sthe skiing?
15:01:38 <mlavalle> haleyb: hi
15:01:41 <john-davidge> mlavalle: Very hot! Probably got the last week of the snow season
15:01:49 <mlavalle> LOL
15:02:04 <mlavalle> #topic Announcements
15:02:54 <mlavalle> Pike-1 is fast approaching: Apr 10 - 14
15:03:13 <mlavalle> #link https://releases.openstack.org/pike/schedule.html
15:04:04 <mlavalle> Also, the Boston Summit is a little more than a month away
15:04:12 <mlavalle> #link https://www.openstack.org/summit/boston-2017/
15:04:25 <mlavalle> May 8 - 11
15:04:40 <mlavalle> I am scheduled to be there the entire week
15:04:52 <mlavalle> I know haleyb will be there
15:05:11 <mlavalle> Hoping to see john-davidge as well
15:05:15 <haleyb> yes, i'll be there
15:05:18 <john-davidge> I'm still unsure, remaining hopeful
15:05:41 <mlavalle> Cool!
15:05:54 <mlavalle> Any other announcements?
15:06:52 <mlavalle> #topic Bugs
15:07:32 <mlavalle> First up today is https://bugs.launchpad.net/neutron/+bug/1627424
15:07:32 <openstack> Launchpad bug 1627424 in neutron "FlushError on IPAllocation" [High,In progress] - Assigned to Miguel Lavalle (minsel)
15:08:35 <mlavalle> I have been discussing this one with kevinbenton. The next step is that I am going to change IPAllocations are added to the port
15:09:11 <mlavalle> To cover that work I filed this bug: https://bugs.launchpad.net/neutron/+bug/1676235
15:09:11 <openstack> Launchpad bug 1676235 in neutron "IPAM inserts a port's IP allocations directly in the database, instead of appending them to the fixed_ips relationship of the port" [Medium,Confirmed] - Assigned to Miguel Lavalle (minsel)
15:09:47 <mlavalle> In a nutshell I am going to add the IPAllocations to the port through the fixed_ips relationship
15:10:44 <mlavalle> That will help with the enginefacade implementation and should also have an effect on the FlushError
15:10:55 <mlavalle> Any comments or recommendations?
15:11:10 <john-davidge> sounds good, will keep an eye on the patch
15:12:10 <mlavalle> ok, moving on
15:12:22 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1610483
15:12:22 <openstack> Launchpad bug 1610483 in neutron "Pluggable IPAM rollback mechanism is not robust" [High,In progress] - Assigned to Aliaksandr Dziarkach (aliaksandr-dziarkach)
15:13:53 <mlavalle> kevinbenton commented on the proposed fix. He didn't see it really addressing the bug and recommended that, if a much better solution is not proposed, remove the rollback mechanism from the IPAM API
15:14:01 <mlavalle> any opinions about it?
15:15:21 <mlavalle> ok, cool
15:15:37 <haleyb> just wondering if anyone from infoblox is around to comment
15:16:31 <mlavalle> No, I don't see john-belamaric. I will ping him and seek his opinion
15:16:33 <haleyb> i don't see jon around either, so guess now
15:17:31 <mlavalle> #action mlavalle to seek john-belamaric opinion on next step for bug 1610483
15:17:31 <openstack> bug 1610483 in neutron "Pluggable IPAM rollback mechanism is not robust" [High,In progress] https://launchpad.net/bugs/1610483 - Assigned to Aliaksandr Dziarkach (aliaksandr-dziarkach)
15:17:53 <mlavalle> does that make sense?
15:18:14 <haleyb> yup
15:18:57 <mlavalle> at the very least I will try to brainstorm how a real rollback mechanism should behave :-)
15:19:54 <mlavalle> Next up is https://bugs.launchpad.net/neutron/+bug/1627480
15:19:54 <openstack> Launchpad bug 1627480 in neutron "create_port can succeed without returning fixed_ips on all requested subnets" [High,Confirmed] - Assigned to James Anziano (janzian)
15:20:10 <mlavalle> Janzian and I have spent some time with his one lately
15:21:17 <janzian> We had been suspecting it might be fixed in current master, but some occurrences popped up yesterday that somewhat dashed those hopes :(
15:21:28 <mlavalle> Well
15:22:20 <mlavalle> we discovered many of the hits were produced by project openstack/puppet-openstack-integration
15:22:52 <mlavalle> which seems to be using the latest stable version to execute its tests
15:23:35 <mlavalle> The other hits are produced by project openstack-dev/devstack
15:23:57 <mlavalle> and spent some time this morning checking the failures in this project
15:24:15 <mlavalle> They seem to be all related to non voting jobs in that project
15:24:36 <mlavalle> I will dig deeper and update the bug with findings
15:25:06 <mlavalle> BTW, no hist triggered by Neutron project
15:25:16 <janzian> Cool, I hadn't realized the devstack failures were non-voting
15:26:24 <mlavalle> I didn't have time to go through all the hist, but I saw at least 4. so this is still tentative
15:27:36 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1509004
15:27:36 <openstack> Launchpad bug 1509004 in neutron ""test_dualnet_dhcp6_stateless_from_os" failures seen in the gate" [High,Confirmed] - Assigned to James Anziano (janzian)
15:28:03 <mlavalle> I see 2 hits over the past 7 days
15:28:46 <mlavalle> But it's been really quiet over the past 2 weeks
15:28:53 <janzian> The first hit is a different test case producing the same error. I hadn't seen the second hit before now though
15:29:37 <mlavalle> It's been quiet over the past 2 weeks
15:29:52 <mlavalle> Let's dig into those 2 failures, see if they are legit
15:31:04 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1672701
15:31:04 <openstack> Launchpad bug 1672701 in neutron "DetachedInstanceError on subnet delete" [High,Confirmed] - Assigned to venkata anil (anil-venkata)
15:31:22 <mlavalle> I think the fixes to the stable branches were realesed
15:31:32 <mlavalle> and it doesn't affect master
15:31:46 <mlavalle> I just wanted to confirm with haleyb it is closed
15:31:57 <mlavalle> since he was involved in merging the fix
15:32:06 * haleyb looks
15:32:49 <haleyb> yes, it's in stable ocata and newton
15:33:33 <mlavalle> haleyb: ok, I'll close it, so it doesn't pop up in our Launchpad queries
15:33:58 <haleyb> i just did
15:34:24 <mlavalle> thanks :-)
15:34:51 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1675187
15:34:51 <openstack> Launchpad bug 1675187 in neutron "Floating IPs not removed on rfp interface in qrouter" [High,In progress] - Assigned to Brian Haley (brian-haley)
15:35:05 <mlavalle> Again, it showed up in the query to Launchpad
15:35:27 <mlavalle> haleyb: do you want to discuss it here or keep it with the DVR team?
15:35:49 <haleyb> https://review.openstack.org/451859 was just proposed by me 20 minutes ago :)
15:36:11 <haleyb> i can keep it on dvr list since it's dvr-specific
15:36:47 <mlavalle> ok, I won't include it in this meeting
15:37:20 <mlavalle> Any other bugs from the team?
15:38:38 <mlavalle> cool
15:38:45 <mlavalle> #topic Routed Networks
15:39:30 <mlavalle> I just wanted to mention that last week the drivers meeting was cancelled, due to scheduling problems
15:39:58 <mlavalle> it is scheduler for today and the floating ip spec is up for discussion
15:40:06 <mlavalle> any comments john-davidge?
15:40:20 <john-davidge> mlavalle: Is it still scheduled at the earlier time slot?
15:40:34 <john-davidge> mlavalle: I didn;t see the revert merge yet
15:40:55 <mlavalle> john-davidge: no, armax didn't like the new time, so at least for this week, it will take place at the old time
15:41:15 <john-davidge> mlavalle: Ah, ok. Will you be attending? It's too late for me
15:41:24 <mlavalle> yes I will
15:41:41 <john-davidge> mlavalle: Ok, excellent
15:42:03 <mlavalle> ok
15:42:10 <mlavalle> #topic Open Agenda
15:42:21 <mlavalle> Any other topics we should discuss today?
15:42:27 <haleyb> i have one
15:42:37 <mlavalle> the floor is yours haleyb
15:42:46 <haleyb> forgot to add to etherpad, so will have to type it out
15:43:24 <haleyb> a change to deprecate an old dns setting, https://review.openstack.org/#/c/406243 merged recently
15:43:33 <mlavalle> ah yeah
15:43:43 <haleyb> backports were proposed but not appropriate
15:44:25 <haleyb> armax had a question about that value being in neutron.conf versus the agent file in #neutron the other day, we wanted to get your opinion we didn't miss something
15:45:37 <haleyb> the other question he had was about the deprecation not having a relationship to the new value - i.e. the original one could have had something
15:46:16 * haleyb doesn't know how to describe it, but basically the old conf value could have pointed at the new to ease transisiton
15:46:35 <haleyb> mlavalle: so what are your thoughts?
15:46:52 <john-davidge> haleyb: Is the question whether it should be moved back into dhcp_agent.ini and removed from neutron.conf?
15:47:03 <mlavalle> when I proposed to deprecate dhcp_domain from the agent file
15:47:37 <haleyb> mlavalle: yes, that seemed to be part of it
15:47:44 <mlavalle> my thinking was just to stop parameter proliferation, especially with parameters that are doing essentially the same thing
15:47:47 <haleyb> my time machine is broken though
15:49:04 <mlavalle> Before DNS instegration, the decision of what to put in the the dnsmasq files was up to the agent
15:49:27 <haleyb> john-davidge: i don't think so, part was that the contents of neutron.conf could differ on nodes, which seemed almost a config bug, armax might be able to explain better, but don't see him
15:49:34 <mlavalle> When we added DNS integration, that decision moved to the server
15:50:02 <mlavalle> if the DNS integration extension is configured
15:50:15 <john-davidge> haleyb: Right, ok
15:50:39 <mlavalle> so that is why we added dns_domain to neutron.conf
15:51:35 <mlavalle> when dns integration is present, the agent will take the hostname from the port data it retrives from the server
15:51:41 <mlavalle> are you with me?
15:52:02 <haleyb> mlavalle: right.  and the dhcp agent is typically running on a controller, so i was a little confused by his questions
15:52:17 <haleyb> ok, so hostname from port data, then domain from server data?
15:52:35 <mlavalle> correct
15:52:59 <mlavalle> but what if the deployment oesn't configure the dns extension
15:53:01 <mlavalle> ?
15:53:27 <mlavalle> the port data won't have dns_assignment attribute
15:53:41 <mlavalle> so we revert to taking the decision locally in the agent
15:54:58 <mlavalle> makes sense?
15:55:04 <haleyb> that seems ok, but you're the expert :)
15:55:20 <mlavalle> now, I may be making one conceptual error
15:55:33 <mlavalle> do we assume that the agent can read neutron.conf?
15:56:50 <haleyb> i would hope so, at least on devstack it's started with both neutron.conf and it's ini
15:57:25 <haleyb> mlavalle: we might just need to find armax later to discuss
15:57:44 <mlavalle> being that the case, when I marked dhcp_domain for deprecation, I was just trying to avoid parameter proliferation
15:58:17 <haleyb> then i went a really removed it since it was like two releases old
15:58:37 <mlavalle> exactly
15:59:19 <haleyb> we're about out of time...
15:59:32 <mlavalle> I can ping armax later and when I find him, I'll ping you
15:59:46 <mlavalle> Thanks for attending !
15:59:46 <haleyb> sounds good
15:59:55 <mlavalle> #endmeeting