15:00:51 <carl_baldwin> #startmeeting neutron_l3
15:00:52 <openstack> Meeting started Thu Feb  4 15:00:51 2016 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:53 <johnbelamaric> hello
15:00:55 <openstack> The meeting name has been set to 'neutron_l3'
15:01:10 <carl_baldwin> #topic Announcements
15:01:17 <pavel_bondar> hi
15:01:52 <carl_baldwin> #link http://docs.openstack.org/releases/mitaka/schedule.html
15:02:18 <carl_baldwin> Mitaka-3 is in less than a month.
15:02:56 <carl_baldwin> The good news is that we've had some stuff finish merging and some stuff that is very close.  But, there are others that are going to need a very focused effort.
15:03:13 <carl_baldwin> Also, everyone knows about the mid-cycle at the end of the month?
15:03:35 <mlavalle> carl_baldwin: the etherpad is here https://etherpad.openstack.org/p/neutron-mitaka-midcycle
15:03:37 <carl_baldwin> I need to finalize my plans.
15:03:43 <carl_baldwin> mlavalle: Thanks
15:04:10 <diltram> hi
15:04:24 <carl_baldwin> I think I've worked it out to go more than just a day and a half, which was my original plan.
15:04:52 <carl_baldwin> Any other announcements?
15:05:23 <carl_baldwin> #topic Bugs
15:05:27 <mlavalle> hi
15:05:29 <carl_baldwin> #chair mlavalle
15:05:30 <openstack> Current chairs: carl_baldwin mlavalle
15:05:57 <mlavalle> so this week we have the same bugs from last week + 1
15:06:06 <mlavalle> first up is https://bugs.launchpad.net/neutron/+bug/1478100
15:06:07 <openstack> Launchpad bug 1478100 in neutron "DHCP agent scheduler can schedule dnsmasq to an agent without reachability to the network its supposed to serve" [High,In progress] - Assigned to Cedric Brandily (cbrandily)
15:06:48 <mlavalle> This one has had a patchset ready for review for several weeks: https://review.openstack.org/#/c/205631/
15:07:14 <mlavalle> I encourage the team to take some time and take a look. I'll do it later today
15:07:45 <carl_baldwin> It has gone somewhat stale.  I'll take another look before the end of the week.
15:07:56 <mlavalle> any other comments on this?
15:08:29 <mlavalle> ok, next up is https://bugs.launchpad.net/neutron/+bug/1527089
15:08:30 <openstack> Launchpad bug 1527089 in neutron "[ipam] Port ID is not present in port dict that is passed to AddressRequestFactory" [High,In progress] - Assigned to Carl Baldwin (carl-baldwin)
15:09:06 <mlavalle> This one just needs one additional +2
15:09:19 <mlavalle> carl_baldwin already gave it a +2
15:09:29 <mlavalle> and the +1's have piled in
15:09:40 <mlavalle> https://review.openstack.org/#/c/259697/
15:09:45 <carl_baldwin> It has had other +2s.  haleyb, could you take a quick look?
15:10:30 <haleyb> carl_baldwin: i have a +1 there, but i'll take another look
15:10:37 <carl_baldwin> I made an update to it after garyk (I think) blessed it because the patch set had regressed in one area that I thought was important enough to fix.
15:10:55 <haleyb> that whole "l3 core" thing :)
15:11:25 <carl_baldwin> haleyb: Doesn't this fit?  It is IPAM.
15:12:07 <carl_baldwin> I think it fits in our purview
15:12:28 <haleyb> ok, i tend to be cautious, but IP is not L2
15:13:11 <mlavalle> any other comments?
15:13:25 <johnbelamaric> haleyb: certainly, but external IPAM systems want to track meta-data about IPs - including their L2 associations
15:13:55 <carl_baldwin> haleyb: I tend to treat anything with l3-ipam-dhcp tag in launchpad as ours.
15:14:49 <carl_baldwin> mlavalle: I think we're good on this one
15:14:53 <mlavalle> ok, moving on
15:15:03 <mlavalle> next up is https://bugs.launchpad.net/neutron/+bug/1541348
15:15:04 <openstack> Launchpad bug 1541348 in neutron "Regression in routers auto scheduling logic" [High,In progress] - Assigned to Oleg Bondarev (obondarev)
15:15:11 <mlavalle> This is the new one
15:15:43 <mlavalle> obondarev_ already proposed a fix for it https://review.openstack.org/#/c/275653/
15:15:54 * carl_baldwin had this one up to review yesterday but didn't get to it. Will today.
15:16:18 <mlavalle> yeah, swami already took a look on it
15:16:52 <mlavalle> any other comments?
15:17:24 <mlavalle> if not, those are all the bugs I got this week. Am I missing something?
15:17:54 <johnbelamaric> ipam migration
15:17:56 <carl_baldwin> mlavalle: Thanks.
15:17:59 <johnbelamaric> one sec, let me find it
15:18:09 <johnbelamaric> #link https://bugs.launchpad.net/neutron/+bug/1516156
15:18:10 <openstack> Launchpad bug 1516156 in neutron "[RFE] IPAM migration from non-pluggable to pluggable" [Wishlist,In progress] - Assigned to Pavel Bondar (pasha117)
15:18:18 <johnbelamaric> i guess it is RFE
15:18:22 <mlavalle> johnbelamaric: yeah, you mentioned it last week, sorry about that ;-(
15:18:34 <diltram> https://bugs.launchpad.net/neutron/+bug/1365461
15:18:35 <openstack> Launchpad bug 1365461 in neutron "HA router should failover if GW address is not reachable" [Medium,In progress] - Assigned to Lubosz Kosnik (diltram)
15:18:38 <johnbelamaric> So, pavel_bondar sent a question to the mailing list
15:18:47 <johnbelamaric> We should discuss in here
15:19:14 <carl_baldwin> johnbelamaric: I haven't read it yet.
15:19:14 <johnbelamaric> main question is - should pluggable be default in Mitaka?
15:19:31 <pavel_bondar> #link http://openstack.markmail.org/search/?q=#query:+page:1+mid:d3eolf77srtwzats+state:results
15:19:40 <johnbelamaric> for all vs. for greenfield as well
15:19:54 <johnbelamaric> so, for all I would say no - we don't want to auto-migrate people on upgrade
15:20:01 <carl_baldwin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085767.html
15:20:18 <carl_baldwin> pavel_bondar: I didn't see your link.  :)
15:20:22 <johnbelamaric> so that means no alembic migration, just an operator run script
15:20:59 <carl_baldwin> johnbelamaric: Right, we're only deprecating the non-pluggable implementation according to our plan.
15:21:29 <carl_baldwin> If we do it automatically, we'd have to remove all of that code now and disable it completely because there is no path for them to get back to it.
15:21:39 <johnbelamaric> carl_baldwin: ok, that's what I thought. if it is deprecated though, it probably shouldn't be the default, right?
15:22:00 <pavel_bondar> carl_baldwin: so another question, do we want to make pluggable ipam default for greenfields in Mitaka?
15:22:55 <carl_baldwin> It is a tricky question.  I kind of want to but would like to see what others think.
15:22:59 <tidwellr> johnbelamaric: it's my understanding that the reference driver handles subnetpools as a no-op, is that correct?
15:24:04 <johnbelamaric> tidwellr: it just calls out to the existing subnet pool operations. in fact I think our driver does too, I don't think we implemented letting our system determine the next subnet - it's still done by the neutron code
15:24:40 <tidwellr> johnbelamaric: ok, so as long as the reference driver gives us parity I'm fine with making it the default
15:24:49 <johnbelamaric> tidwellr: yes, it certainly does
15:25:29 <johnbelamaric> this also reminds me I want to file a RFE that makes IPAM driver per subnet pool (which is how it is designed just htat is not implemented yet)
15:25:43 <tidwellr> I was looking at the reference driver the other day an saw some comments that raised some suspsicions, but I'll take another look
15:26:11 <carl_baldwin> johnbelamaric: ++
15:26:30 <tidwellr> johnbelamaric: ah, thats what it was that had me raise an eyebrow
15:26:33 <carl_baldwin> Let's take the discussion to the ML.  I've started to draft a reply and will finish it up this morning.
15:26:45 <johnbelamaric> carl_baldwin: ok, thanks
15:28:16 <carl_baldwin> diltram: I'll take a look at that bug you linked also.
15:28:28 <diltram> I prepared a fix for that bug and would like to ask for reviews. Garyk came give -1 and go away without leaving any comments
15:28:40 <diltram> carl_baldwin: thanks
15:28:52 <carl_baldwin> Any other bugs?
15:29:45 <carl_baldwin> ok, moving on..
15:30:00 <carl_baldwin> #topic Routed network segments
15:30:18 <carl_baldwin> Last week I was iterating mostly on the Nova side.
15:30:46 <carl_baldwin> #link https://review.openstack.org/#/c/263898/
15:31:19 <carl_baldwin> I think that is pretty close.  Though, I'm a little nervous about the cross-project collaboration aspects of this.
15:31:54 <blogan> carl_baldwin: do you think both specs can get merged by M-3?
15:31:56 <carl_baldwin> I think I'd like to focus on making sure this gets up on Nova's priority board and has someone interested from the Nova side in its success.
15:32:43 <carl_baldwin> blogan: Do you mean the implementation of both?
15:32:48 <carl_baldwin> If so, there is no chance.
15:32:51 <blogan> carl_baldwin: just the spec
15:32:53 <blogan> specs
15:33:03 <carl_baldwin> blogan: I'd like to see them both merge this month.
15:33:08 <blogan> carl_baldwin: oh i know the implementation doesn't have a chance :)
15:33:08 * mlavalle waves at blogan
15:33:32 <carl_baldwin> The next two weeks would be great but there is some work to do to get the details spec'd out.
15:33:59 <mlavalle> carl_baldwin: we are going to work on it during the midcycle, right?
15:34:02 <carl_baldwin> I'm not sure if Nova is actually open to Newton specs yet.
15:34:06 * blogan glares at mlavalle
15:34:10 * blogan waves
15:34:15 <mlavalle> LOL
15:34:16 <carl_baldwin> mlavalle: Yes
15:34:32 <carl_baldwin> Who will be at the mid-cycle with interest in working on this?
15:34:32 <mlavalle> ++
15:34:40 <mlavalle> o/
15:35:07 <carl_baldwin> Also, on the Neutron side, I've got a few more details worked out and need to get my new version of the spec up by the end of the week.
15:35:14 <blogan> i have interest in helping out in whatever way, but won't be at the midcycle
15:36:10 <carl_baldwin> I've been throwing around the idea in my head of having virtual sprints or regular meetings devoted to this topic, at least until the ball gets rolling.
15:36:31 <mlavalle> probably a good idea
15:36:57 <carl_baldwin> I'll propose a meeting to the meeting repo and send a link to that review to the ML.
15:37:19 <carl_baldwin> #action carl_baldwin will propose a meeting slot for routed networks collaboration
15:37:26 <blogan> excellent
15:37:38 <carl_baldwin> Okay, that's all.
15:37:51 <carl_baldwin> #topic BGP dynamic routing
15:37:58 <tidwellr> hi
15:38:00 <carl_baldwin> tidwellr: vikram:  You're up.
15:38:01 <vikram> hi
15:38:50 <tidwellr> I've got new patch sets going that address some of the review comments, running it e2e right now for some sanity checks
15:39:10 <vikram> working on the fullstack tests
15:39:34 <tidwellr> functionally, I think we have announcements for centralized routers nailed
15:39:45 <vikram> ++
15:40:33 <tidwellr> once I push these changes I have queued up we continue the focus on making the code is easily separable from the main repo
15:41:21 <carl_baldwin> tidwellr: Great.
15:41:33 <tidwellr> DVR support comes with a follow-on patch to the reviews that give us centralized router support
15:42:58 <tidwellr> I think the recent reviewer attention has been great, let's just keep it up
15:43:04 <carl_baldwin> tidwellr: Will you have an update to the crud patch soon?
15:43:09 <vikram> I got to rework on the comments
15:43:19 <carl_baldwin> ... or does it need another look from reviewers?
15:43:25 <tidwellr> carl_baldwin: yes
15:43:58 <carl_baldwin> tidwellr: vikram: ping me as soon as you have something new.  Let's tighten up the review cycle on these.
15:44:02 <tidwellr> carl_baldwin: I've got changes queued for all patches (except the DVR patch, ignore it for now)
15:44:17 * carl_baldwin ignoring the DVR + BGP patch for now.
15:44:30 <vikram> tidwellr: when you can post them?
15:45:17 <tidwellr> in a few hours, I'm testing e2e so that involves external routers and such
15:45:37 <carl_baldwin> tidwellr: vikram:  Anything else?
15:45:49 <tidwellr> not from me
15:46:02 <vikram> nothing from my end.. just need for reviewers to the party
15:46:06 <vikram> *more
15:46:40 <carl_baldwin> Thanks
15:46:40 <carl_baldwin> #topic DNS
15:46:42 <carl_baldwin> mlavalle: You're up.
15:46:47 <mlavalle> hi
15:46:58 <mlavalle> so I've been 100% focused on the nova side
15:47:16 <mlavalle> johnthetubaguy reviewed the patchset yesterday
15:47:19 <carl_baldwin> The way I see it, priority #1 is the Nova patch.  #2 is the technical debt pointed out by armax.
15:47:35 <carl_baldwin> mlavalle: How did that go?  I haven't seen it yet.
15:47:44 <mlavalle> he had concerns about the additional neutron client call to update the port
15:48:00 <mlavalle> so I proposed last night an alternate implementation
15:48:38 <mlavalle> where he reuse the current port create / update calls if port binding extension is not enabled in the Neutron side
15:48:58 <mlavalle> becasue in that case the neutron client uses the user context
15:49:47 <mlavalle> in case port binding is enabled, I also added a config param, to let the user admin to specify wheher dns_name should be added to all ports or only to ports on networks with dns_domain
15:50:10 <mlavalle> that way we minimize the number of additional port updates
15:50:59 <mlavalle> the patchset is up, it passed tests and I pinged John earlier today to alert him
15:51:43 <mlavalle> when I am not working on that, I have been working on a new chapter to the networking guide with all that needs to be known to use DNS integration
15:51:45 <carl_baldwin> mlavalle: I'm not sure about the config param.  I'd prefer it always sent it.
15:52:35 <mlavalle> carl_baldwin: noted (and I agree). I want to keep the dialogue going on the Nova side
15:53:19 <mlavalle> that's all I have this week
15:53:50 <carl_baldwin> mlavalle: Great, keep the review cycles small so reviewers stay engaged.  Any ideas on a second core reviewer?  Does John have any suggestions?
15:54:29 <mlavalle> not yet. I'll think about that
15:54:41 <carl_baldwin> mlavalle: It would be good to get another engaged soon.
15:54:47 <mlavalle> ++
15:54:52 <carl_baldwin> mlavalle: Great work.  Thanks.!
15:54:57 <carl_baldwin> #topic Address Scopes
15:55:09 <carl_baldwin> I think we're about ready to wrap this one up.
15:55:49 <carl_baldwin> The final major patch has one +2, I've asked salv-orlando to take another look as the approver and then I think we can get another core on it soon.
15:56:16 <carl_baldwin> After that, there is a bug fix to notify routers of changes to subnetpools and one more patch with functional tests.
15:57:01 <carl_baldwin> Many thanks to xiaohui for lots of help shaking out the bugs.
15:57:20 <johnbelamaric> carl_baldwin: excellent, that's great news
15:57:21 * carl_baldwin hopes he got his nick right.
15:57:33 <carl_baldwin> johnbelamaric: thanks
15:57:37 <carl_baldwin> That's all I have.
15:57:43 <carl_baldwin> #topic Open Discussion
15:58:06 <johnbelamaric> FYI, I created that aforementioned RFE here: #link https://bugs.launchpad.net/neutron/+bug/1541895
15:58:08 <openstack> Launchpad bug 1541895 in neutron "[RFE] [IPAM] Make IPAM driver a per-subnet pool option" [Wishlist,Confirmed]
15:58:23 <carl_baldwin> johnbelamaric: ack
15:59:13 <carl_baldwin> johnbelamaric: Will you have the resources to drive this?
15:59:30 <mlavalle> carl_baldwin, johnbelamaric: should we put the IPAM topic back in the agenda, to track this RFE's?
15:59:31 <johnbelamaric> carl_baldwin: mmm. maybe. let me see what I can do.
16:00:06 <johnbelamaric> carl_baldwin: you can assign it to me - i guess I can do that :)
16:00:09 <carl_baldwin> We're out of time.
16:00:16 <carl_baldwin> #endmeeting