15:00:19 <carl_baldwin> #startmeeting neutron_l3
15:00:25 <openstack> Meeting started Thu Jul 23 15:00:19 2015 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:26 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:28 <openstack> The meeting name has been set to 'neutron_l3'
15:00:48 <carl_baldwin> #topic Announcements
15:00:49 <vikram> hi
15:01:08 <carl_baldwin> Liberty-2 is right around the corner.  It always comes so quickly.
15:01:24 <carl_baldwin> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
15:01:39 <johnbelamaric> hello
15:02:05 <carl_baldwin> Liberty-3 is around the end of September.  New functionality needs to be merged by then.
15:02:10 <john-davidge> Looks like IPAM will all be in in time for L2 :D
15:02:12 <yamahata> hello
15:02:18 <john-davidge> Well done everyone
15:02:27 <pavel_bondar> hi
15:02:28 <carl_baldwin> *merged* which means it should be posted for review long before and working.
15:03:11 <carl_baldwin> Also, I’m going to be on vacation with my family starting today and going through next week.
15:03:13 <johnbelamaric> john-davidge: yes, it's been a long journey. thanks to pavel_bondar especially since he did all the work :)
15:03:58 <johnbelamaric> carl_baldwin: have a great vacation, well deserved!
15:04:01 <carl_baldwin> johnbelamaric: +1
15:04:19 <carl_baldwin> Great work on IPAM.  We hit a great milestone with that work.
15:04:22 <neiljerram> carl_baldwin: indeed, happy vacation!
15:04:44 <john-davidge> carl_baldwin: Anywhere nice?
15:05:31 <carl_baldwin> With my wife’s family in Kentucky.  It can be nice there.
15:05:39 <pavel_bondar> carl_baldwin and johnbelamaric without your wise reviews and ideas I think it would take much more time, thank you!
15:05:47 <carl_baldwin> I intend to read the ML and do a review here and there.
15:06:06 <carl_baldwin> Any other announcements?
15:06:14 <carl_baldwin> #topic Bugs
15:06:27 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1471316 is the one I’d like to talk about.
15:06:28 <openstack> Launchpad bug 1471316 in neutron "_get_subnetpool_id does not return None when a cidr is specified and a subnetpool_id isn't." [High,In progress] - Assigned to John Davidge (john-davidge)
15:07:21 <carl_baldwin> I’ve been trying to convert myself to this bug’s point of view.
15:07:35 <john-davidge> carl_baldwin: How can I help to convert you? :)
15:08:28 <carl_baldwin> I’m still hung up on on the fact that the mere presence of a cidr in the request will change what subnet pool will be used.  In Liberty, this will also have implications on what address scope will be used.
15:09:00 <carl_baldwin> It seems to add a dimension to the request that is surprising.
15:09:17 <john-davidge> carl_baldwin: The impact of the presence of a cidr is documented in the subnet allocation spec, so it seems to me that that was the intention from the beginning
15:09:47 <carl_baldwin> john-davidge: That was a mistake, actually.
15:10:32 <john-davidge> carl_baldwin: I guess my main point with rasing this issue is that the current behaviour is unpredicatable from the user’s POV. Requesting a subnet with a CIDR but no subnetpool
15:10:34 <john-davidge> ...
15:11:06 <john-davidge> carl_baldwin: subnetpool_id yields a different result depending on whether the admin has set a default subnet pool
15:11:18 <john-davidge> which the user doesnt know until they make the request
15:11:46 <tidwellr> isn't that the point with prefix delegation though?
15:11:55 <john-davidge> the result being that ALL subnet-create requests intending to use the implicit pool have the include subnetpool_id = none
15:12:05 <carl_baldwin> john-davidge: It sounds like the real problem is with the design of the default subnet pool config option and its affect on the API.
15:13:16 <carl_baldwin> john-davidge: What you say is true with or without a cidr specified that the user will not know whether the admin has set a default.
15:13:18 <john-davidge> carl_baldwin: Yes, it looks like the default pool is currently treated as the new implicit pool if it is set, rather than the default pool to be used when the user expresses their desite to use a pool without specifying which one
15:14:17 <john-davidge> carl_baldwin: Yes, but not specifying a CIDR is a clear indication that the user doesn’t wish to use the implicit pool.
15:14:42 <john-davidge> carl_baldwin: Whereas prividing one seems ambiguous at best
15:15:18 <john-davidge> tidwellr: Could you expand on that?
15:15:18 <carl_baldwin> john-davidge: Did you mean to say “… that the user does wish to use the implicit pool”
15:16:21 <john-davidge> carl_baldwin: No. implicit pool != default pool
15:16:25 <carl_baldwin> john-davidge: I think that specifying cidr is independent of specifying the subnet pool.  I think it would be a mistake to try to infer the user’s intent around subnet pools from the presence of a cidr.
15:16:28 <tidwellr> john-davidge: my understanding is that the idea with prefix delegation is to effectively replace the implicit pool with an explicit pool under the hood
15:17:32 <carl_baldwin> john-davidge: I know that but I thought maybe you wanted “does” instead of “doesn’t” since your proposed solution seems to fall back on the implicit pool when the user does not specify cidr.
15:17:42 <john-davidge> tidwellr: No, we’d don’t want to remove the users ability to use the implicit pool. Only give them the added option of using PD if they aren’t concered with the CIDR they get
15:19:09 <john-davidge> carl_baldwin: The opposite actually. The implicit pool is used when the user provides a CIDR. Otherwise the default is used.
15:19:47 <john-davidge> carl_baldwin: This allows existing subnet-create calls to function when a default has been set
15:19:49 <carl_baldwin> john-davidge: okay.  I did read it wrong.  You’re right.
15:20:17 <carl_baldwin> I actually read “Yes, but specifying a cidr…”  Sorry.
15:20:28 <john-davidge> carl_baldwin: no worries :)
15:21:41 <john-davidge> carl_baldwin: I guess my main point is that I don’t think defining a default pool should break the existing behaviour. If the user doesnt specify a cidr then they are clearly deviating from the legacy API and can be assumed to understand subnetpools.
15:23:03 <tidwellr> john-davidge: the implicit pool doesn't allocate CIDR's, you must specify a CIDR when using the implicit pool
15:23:57 <john-davidge> tidwellr: Yes, and that’s my point. If the user specifies a cidr but not a subnetpool then I think we should assume they wish to use the implicit pool.
15:24:17 <carl_baldwin> I agree that the wisdom of the default pool config should be called in to question.
15:24:23 <john-davidge> tidwellr: whether a default pool is set or not
15:25:16 <john-davidge> carl_baldwin: Yes. at the moment the default overrides the implicit, which I think was a mistake.
15:25:38 <tidwellr> john-davidge: I think I understand you now, I agree that the default pool config could use a little more thought
15:25:56 <carl_baldwin> I think we should consider deprecating it.
15:26:44 <carl_baldwin> We’ve used a lot of meeting time.  Let’s move this to the ML.  I’ll add another note to the bug.
15:27:10 <john-davidge> Sure
15:27:16 <carl_baldwin> #topic Routed network segments
15:29:27 <carl_baldwin> amuller: ijw_: Around?
15:29:47 <carl_baldwin> I don’t know if we want to use meeting time for this
15:30:28 <carl_baldwin> But, I wanted to point out the discussion on the ML about this.  It will take some time to work out a way to model this that is acceptible to the community.
15:31:10 <neiljerram> carl_baldwin: yes, seems like it
15:31:11 <mlavalle> carl_baldwin: this is the email thread:  https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg58876.htm
15:31:22 <mlavalle> I also posted it in the wiki page
15:31:22 <carl_baldwin> Thanks for the link.
15:32:45 <carl_baldwin> Let’s keep it on the ML for a little while longer.  I’m going to attempt to break it in to a couple of topics to focus the discussion a little better.  For example, how Nova and Neutron will work together to schedule.  Also, how to model the segment in Neutron.
15:33:25 <carl_baldwin> This will likely have a big effect on BGP but I think we can still make some progress on BGP.
15:33:27 <carl_baldwin> #topic BGP dynamic routing
15:33:32 <carl_baldwin> tidwellr: vikram: hi
15:33:38 <tidwellr> hi
15:33:41 <vikram> hi
15:34:25 <carl_baldwin> I sense there is really good progress being made on this from some private reports I’ve heard from you both.
15:35:08 <vikram> yes. major hurdles with agent scheduling and driver crossed :-).. it's working fine..
15:35:37 <tidwellr> yes, we've got server-side working pretty well and the agent side working pretty well and just need to bring them together with RPC implementation
15:35:59 <vikram> +1
15:36:24 <carl_baldwin> Very cool!
15:36:41 <carl_baldwin> Any reviews or anything to bring up to the team?
15:37:14 <vikram> i want to finish the testing and then post patches
15:37:29 <vikram> will submit next week about agent_schld and driver
15:37:40 <vikram> +cli
15:37:47 <tidwellr> I've a got a new patch set for https://review.openstack.org/#/c/201621/ marinating in my sandbox
15:38:48 <tidwellr> discovering what routes to advertise is proving to be a challenge, the good news is that it really comes to down to filling out DB queries inside a small handful of methods, not a lot of code
15:39:15 <carl_baldwin> tidwellr: +1  I kind of knew it would be a challenge.
15:39:54 <carl_baldwin> tidwellr: vikram:  We’re looking forward to the updated reviews.  Please send me (and others interested) a quick ping when they’re up.
15:40:12 <carl_baldwin> #topic IPAM
15:40:16 <vikram> carl_baldwin:sure
15:40:23 <carl_baldwin> johnbelamaric: pavel_bondar: hi
15:40:33 <tidwellr> I'm having to create 2 different service plugin implementations, 1 that's basic and works with all Neutron plugins, and 1 that's optimized for ML2, look for it in the next patch set
15:40:33 <johnbelamaric> hi
15:40:35 <carl_baldwin> Again, great job.  We’ve hit a great milestone.
15:40:40 <johnbelamaric> looks like we are having an issue in the gate though
15:40:46 <johnbelamaric> it *looks* similar to
15:40:47 <johnbelamaric> #link https://bugs.launchpad.net/neutron/+bug/1434278
15:40:48 <openstack> Launchpad bug 1434278 in neutron "spurious UT failure 'L3_ROUTER_NAT' keyerror" [High,Fix released] - Assigned to Kevin Benton (kevinbenton)
15:40:52 <johnbelamaric> which was fixed back in March
15:41:11 <johnbelamaric> we are consistently getting that KeyError
15:41:20 <johnbelamaric> can't see what it has to do with our code though
15:41:22 <carl_baldwin> tidwellr: ack, the ML2 optimized one because of the tangled nature of DVR and ML2.
15:42:03 <johnbelamaric> pavel_bondar: did you find anything suspicious?
15:42:17 <pavel_bondar> nothing about this error
15:42:23 <pavel_bondar> but also we have second issue with py34 tests
15:42:35 <pavel_bondar> and found something about this one
15:43:29 <pavel_bondar> error appeared in the morning today after merging commit that enables more tests to run
15:43:47 <pavel_bondar> and error we have is not
15:44:14 <pavel_bondar> sorry, not finished
15:44:40 * carl_baldwin was hoping the patch had just merged. He didn’t confirm.  :(
15:45:32 <pavel_bondar> test_ipam_pluggable_backend was added to py34 today in the morning, but our patch adds more tests to that, which are not py34 compatible
15:45:56 <pavel_bondar> possible fix for this area is https://review.openstack.org/#/c/203691/
15:46:06 <john-davidge> pavel_bondar: Ah, I guess that expalins it then
15:47:22 <pavel_bondar> but probably more simple fix is turn off py34 tests back for new ipam tests, unless 203691 is merged
15:47:54 <carl_baldwin> pavel_bondar: It is merged.
15:48:26 <pavel_bondar> sorry, wrong id
15:48:37 <pavel_bondar> https://review.openstack.org/#/c/204791/
15:49:31 <pavel_bondar> and yeah, right now it has failures for jenkins, so I don't expect it will be merged soon
15:50:22 <pavel_bondar> Issue in py34 tests I see is: TypeError: You cannot set Response.body to a text object (use Response.text)
15:50:38 <carl_baldwin> pavel_bondar: Thanks for your persistence.
15:50:39 <pavel_bondar> and 204791 stands for fixing that
15:50:55 <carl_baldwin> pavel_bondar: That makes sense.
15:51:07 <carl_baldwin> I’ll keep this review up along with yours and watch it.
15:51:55 <carl_baldwin> Anything else to discuss in this meeting?
15:51:59 <johnbelamaric> should we disable py34 tests for ipam for now and add another patch to re-enable after the other fix is in?
15:52:10 <johnbelamaric> to break the dependency
15:52:32 <carl_baldwin> johnbelamaric: It won’t hurt to floating that in a patch.  To me, it seems reasonable.
15:53:10 <carl_baldwin> We’re 8 minutes to the end of the meeting.  I wanted to hit DNS.
15:53:13 <carl_baldwin> #topic DNS
15:53:16 <carl_baldwin> mlavalle: hi
15:53:20 <johnbelamaric> ok. then just have to figure out the KeyError, don't suppose anyone has ideas on that
15:53:35 <mlavalle> carl_baldwin: hi
15:54:05 <mlavalle> carl_baldwin: I re-implemented the internal dns with the "data base light' approach we discussed last friday
15:54:35 <carl_baldwin> mlavalle: Is it on gerrit?
15:54:36 <mlavalle> https://review.openstack.org/#/c/200952/
15:54:39 <carl_baldwin> :)
15:54:54 <mlavalle> i got stuck with some alembic issues earlier this week
15:55:20 <mlavalle> but yesterday i had a nice conversation with kevinbenton, and i think i figured it out
15:55:37 <mlavalle> i will confirm with HenryG the solution as soon as we finisg this meeting
15:55:55 <mlavalle> and i think i will have this working at the end of the day or tomorow
15:56:14 <carl_baldwin> mlavalle: Great.
15:56:22 <mlavalle> it boils down to only adding dns_name to the ports table
15:56:48 <mlavalle> moving all the dns 'computation' to the server, deriving all the data from the dns_label field
15:56:58 <mlavalle> dns_name ^^^^
15:57:24 <mlavalle> and i'm starting the externasl side as well
15:57:36 <mlavalle> so that's my status today
15:57:39 <carl_baldwin> mlavalle: So, a dns_name is essentially what will come from Nova’s hostname, right?  Could be a DNS label, PQDN, or FQDN, right?
15:57:47 <mlavalle> right
15:58:09 <carl_baldwin> mlavalle: That sounds about right to me.
15:58:33 * carl_baldwin encourages reviewers to review.
15:58:42 <carl_baldwin> Anything else?
15:58:51 <mlavalle> that's it ffrom me
15:59:34 <vikram> Address scope patches are under review
16:00:13 <carl_baldwin> vikram: Thanks.  We didn’t quite get to that topic.  I’ve been derailed on network segments.  I need to get the rest of my implementation up on gerrit too.
16:00:23 <carl_baldwin> #endmeeting