15:02:57 <carl_baldwin> #startmeeting neutron_l3
15:02:58 <openstack> Meeting started Thu Nov 13 15:02:57 2014 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:01 <openstack> The meeting name has been set to 'neutron_l3'
15:03:10 <carl_baldwin> #topic Announcements
15:03:17 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:03:36 <carl_baldwin> I did not take the time yesterday to update the agenda.  I think it is probably a little bit out of date.
15:04:37 <carl_baldwin> The mid-cycle has been announced but I think the date is still in question.
15:04:38 <carl_baldwin> #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/050128.html
15:05:10 <carl_baldwin> Here is the wiki:  https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint
15:05:31 <carl_baldwin> I plan to be there for either week.
15:05:43 <carl_baldwin> #link https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint
15:06:10 <carl_baldwin> Summit was great.
15:06:15 <carl_baldwin> Any other announcements?
15:06:35 <yamamoto> nothing from me
15:07:11 <carl_baldwin> Okay.
15:07:32 <carl_baldwin> I guess I’ll just wing it on the agenda.  I’ll take some time today to freshen up the agenda on the wiki.
15:07:50 <carl_baldwin> #topic l3-high-availability
15:07:58 <carl_baldwin> safchain: amuller:  Anything new here?
15:09:06 <carl_baldwin> #topic bgp-dynamic-routing
15:09:08 <carl_baldwin> devvesa: ping
15:09:16 <devvesa> hi
15:09:29 <carl_baldwin> I talked to a lot of people at the summit who are interested in this.
15:10:04 <devvesa> do they use case (or idea) fit with current spec?
15:10:26 <carl_baldwin> Many of them, yes.  This is outside of the BGPVPN crowd.
15:11:00 <devvesa> yes, it seems so. Every time I'm more conviced that we can find very few points in common with them
15:11:02 <carl_baldwin> There is some interest for it with routing to IPv6 networks.
15:11:46 <carl_baldwin> The use case is very specialized.
15:12:07 <carl_baldwin> I see that the spec has a few minor comments.  Will you have a chance to take a look at it?
15:12:13 <devvesa> Mathieu Rohon found some nits in current spec. I will push a new patch
15:13:00 <devvesa> yes, currently I'm caught in Midonet's CI because of our open source stuff
15:13:07 <carl_baldwin> devvesa: Great.  I’ll watch for it.  I think the idea is in pretty good shape.  I’ll reach out to the drivers team about merging it for Kilo.
15:13:21 <devvesa> If I find a free hour I'll review
15:13:25 <devvesa> this week
15:13:37 <devvesa> uhm... maybe beginning of next :)
15:13:46 <carl_baldwin> devvesa: I hope you can find that hour.
15:13:47 <devvesa> (just realised we live on Thursday)
15:14:10 <carl_baldwin> These weeks do go by quickly.
15:14:23 <carl_baldwin> #action devvesa to update the bgp spec
15:14:24 <devvesa> what we need after your approval
15:14:29 <devvesa> ?
15:14:47 <carl_baldwin> devvesa: We need the Neutron drivers team to approve.
15:14:59 <carl_baldwin> #action carl_baldwin will reach out to Neutron drivers team.
15:15:04 <devvesa> cool
15:15:04 <carl_baldwin> devvesa: anything else?
15:15:10 <devvesa> nothing else. thanks
15:15:36 <carl_baldwin> devvesa: Thank you.  It was good to see you at the summit.
15:15:50 <carl_baldwin> #topic L3 Agent Restructuring
15:16:13 <carl_baldwin> I updated my spec and got a lot of feedback yesterday.  I’m partially through addressing that feedback.
15:16:25 <carl_baldwin> #link https://review.openstack.org/#/c/131535/
15:16:38 * pc_m lots of good stuff in there
15:17:20 <carl_baldwin> I haven’t heard any major deal-breaking feedback.  But, there are some sections that need some fleshing out.  I will make it a priority today.
15:17:44 <carl_baldwin> I wanted to ask if anyone read the comments around L132?
15:17:49 <carl_baldwin> #link https://review.openstack.org/#/c/131535/2/specs/kilo/restructure-l3-agent.rst
15:18:15 <pc_m> yes
15:18:33 <carl_baldwin> The comments are around inheritence vs a driver approach.  I realized that my ideas there were not baked enough to have a clear plan.
15:18:40 <carl_baldwin> Thanks for all of your comments, btw.
15:19:19 <carl_baldwin> I’m once again entertaining the idea of using inheritence  for types of routers like DVR, HA, Legacy.
15:20:29 <carl_baldwin> Any more thoughts?
15:20:32 <pc_m> Gut feel is that services seem like capabilities added (composition) for a router.
15:21:00 <pc_m> Router has a VPN capability, router has a FW capability.
15:21:27 <carl_baldwin> pc_m: Agreed.  I think my comment reflects that.  I was hesitent to use any kind of inheritence because I didn’t want to end up with a VPNRouter or a FWaaSRouter.
15:21:38 <pc_m> :)
15:21:54 <carl_baldwin> I’m entertaining the idea of using inheritence to create a DVRRouter, HARouter, etc.
15:21:56 <ChuckC> maybe armando should also take a look?
15:22:20 <ChuckC> oh, well, salvatore is there
15:22:31 <carl_baldwin> Yes, I would welcome armax’s input here.
15:22:50 <carl_baldwin> It is a bit early for him though since DST has ended for the year.  :)
15:22:56 <armax> :)
15:23:01 * armax catching up
15:23:14 <devvesa> so a router that uses DVR and HA is going to be a DVRHARouter?
15:23:21 <carl_baldwin> armax: no worries.
15:23:31 <carl_baldwin> devvesa: I think that would follow, yes.
15:24:09 * carl_baldwin just realized that DVRRouter is redundant.
15:24:54 <devvesa> i have to read the spec. but what it does not fit in my head is the fact that a DVR router depends on l3_agent configuration
15:25:02 <carl_baldwin> If you have some thoughts, feel free to chime in on the review.  I’m not sure this needs to be completely spelled out before we can proceed but I’d like to have a good idea of the direction it will take.
15:25:07 <armax> carl_baldwin: inheritance vs composition needs to be looked at especially when considering how much code can be reause
15:25:11 <devvesa> whereas HA it depends on user call
15:25:16 <devvesa> (just thinking loud)
15:27:24 <carl_baldwin> devvesa: That is true.  DVR does have the extra agent configuration piece.  We might need an extra SNAT class for the centralized part of the router.
15:28:17 <devvesa> i think it will be easy to handle, but keep in mind that opens the door to complex inheritance if there are more kinds of routers in a future
15:28:19 <carl_baldwin> However, igoring the agent configuration part, a DVR can be created much like an HA router.
15:28:46 <carl_baldwin> devvesa: That is a point that I continue to consider.  Thanks.
15:28:56 <carl_baldwin> amuller: hi
15:29:04 <amuller> carl_baldwin: Hey sorry I was interviewing someone
15:29:23 <carl_baldwin> amuller: Looking for a new job?
15:29:31 * carl_baldwin is joking
15:29:34 <amuller> The guy I was interviewing is =D
15:29:52 <amuller> Are you? :)
15:30:09 <carl_baldwin> amuller: We were just wrapping up the discussion on inheritence from the L3 agent spec.
15:30:20 <amuller> I'll read the meeting notes later
15:30:34 <carl_baldwin> I hope to hear your thoughts but I’ll give you a chance to catch up.
15:31:11 <amuller> inheritence vs drivers for different router types? Let's decide that during implementation phase, imo
15:31:13 <carl_baldwin> I think we’ll take the discussion to the review.
15:31:39 <carl_baldwin> amuller: We may need the flexibility to do just that.
15:32:00 <carl_baldwin> #topic neutron-ipam
15:32:17 <carl_baldwin> We had a good discussion about IPAM at the design summit.
15:32:50 <johnbelamaric> i replied to some of your review comments just before this meeting, not sure you would have had a chance to take a look
15:33:07 <carl_baldwin> johnbelamaric: I was just noticing your comments on the review.
15:33:14 <carl_baldwin> https://review.openstack.org/#/c/97967/35/specs/kilo/neutron-ipam.rst
15:33:25 <johnbelamaric> agree that we need to cut the originally proposed interface way back
15:33:29 <carl_baldwin> #link https://etherpad.openstack.org/p/neutron-ipam
15:34:18 <carl_baldwin> johnbelamaric: I think the nature of the interface needs to change too.  I think I get why the interface was done the way it was but I don’t think that is the right permanent solution.
15:34:34 <johnbelamaric> agreed
15:34:36 <carl_baldwin> johnbelamaric: I’d like the interface to be intuitive to use and review.
15:34:59 <johnbelamaric> "minimal surface area" is the way Soheil put it yesterday :)
15:35:51 <carl_baldwin> johnbelamaric: Have you had a chance to look at my straw man?  I had limited time to put it together yesterday so I’m sure it is missing some things.
15:36:10 <carl_baldwin> But, I think it should be enough to illustrate what I had in my mind.
15:36:23 <carl_baldwin> #link http://paste.openstack.org/show/132513/
15:36:32 <johnbelamaric> yes, i did. it looks good for the most part. i think there are a few things - 1) we should let the IPAM system know about the scopes
15:37:04 <johnbelamaric> 2) i think we may want to pass some things like "port object" into the IPAM calls. this enables the IPAM system to make allocation decisions based upon meta-data about the port, vm, tenant, etc.
15:37:19 <carl_baldwin> johnbelamaric: It does know.  L64.  My thought was that the driver would be instantiated once for each scope.
15:37:21 <johnbelamaric> i will do more of a thorough review today
15:37:28 <johnbelamaric> yes
15:38:17 <carl_baldwin> By their definition, scopes are orthogonal.  So, creating an instance per scope makes sense to me.  That way, the rest of the method calls are not cluttered with this detail.
15:38:19 <johnbelamaric> ah, right. driver per scope. hmm. so, when the driver is instantiated it will need some configuration data that goes with it, potentially
15:38:49 <carl_baldwin> address_type is similar.  They are orthogonal.  Hence, the address_type argument no the same line.
15:38:54 <johnbelamaric> yes, that makes sense. so, different scopes managed by different drivers or instances thereof
15:39:04 <johnbelamaric> not sure why address type needs a separate driver instance
15:39:17 <johnbelamaric> but i don't see a problem with it
15:39:23 <carl_baldwin> johnbelamaric: Yes, I assumed that the driver can define its own configuration.
15:40:05 <carl_baldwin> johnbelamaric: address_types are also orthogonal.  Cluttering the rest of the interface with address_type parameters would less clean.
15:40:58 <carl_baldwin> johnbelamaric: I’m writing a new blueprint to follow this blueprint that will add a REST API and new data model so that the reference implementation can take advantage of the scope idea.
15:41:15 <johnbelamaric> so, get_driver is essentially a factory method, right? it doesn't currently allow input of any opaque (ie, possibly driver-specific) config data
15:41:16 <carl_baldwin> I’ll add you folks as reviewers when I have posted the spec.
15:41:27 <johnbelamaric> ok, great. thanks
15:41:43 <johnbelamaric> i will review your proposal closer today
15:41:55 <carl_baldwin> johnbelamaric: Right.  I imagine configuration will be done through config files.  But, there may be some room to enhance this interface.
15:42:24 <johnbelamaric> i think config files is not sufficient, because scopes may be dynamically created and we wouldn't want to have to add config file changes at that time
15:43:02 <carl_baldwin> johnbelamaric: You may a point there.  Let’s continue the discussion about this.
15:43:35 <johnbelamaric> ok
15:43:51 <carl_baldwin> Maybe I should post the base class as a review so that we can annotate it with discussion.
15:44:15 <johnbelamaric> yes, i think that would be helpful
15:44:19 <carl_baldwin> I was being a bit hasty yesterday when I threw it in pastebin.
15:44:40 <carl_baldwin> #action carl_baldwin will post a review with http://paste.openstack.org/show/132513/
15:44:52 <johnbelamaric> ok - quick process question if you don't mind - is it possible for me to modify Soheil's change by uploading a patch that, say, incorporated the changes from this discussion? I am not sure he'll have time this week to update it himself
15:45:44 <johnbelamaric> don't need to know how in this meeting - but want to know it's possible before I make the effort - being new to Gerritt, etc.
15:45:48 <carl_baldwin> johnbelamaric: Yes, that is possible.  You will find that you can’t do a few things like mark it as a WIP but I could do that for you if you want.
15:45:54 <johnbelamaric> great, thanks carl
15:46:21 <carl_baldwin> johnbelamaric: Feel free to ping me for help on that if you need.  The process is simple though.  Just git review -d NNNNN the review.  Amend it and post it like normal.
15:46:32 <johnbelamaric> ok, good
15:46:42 <carl_baldwin> johnbelamaric: Thanks.
15:46:45 <carl_baldwin> Anything else?
15:47:04 <johnbelamaric> not right now on IPAM for me - moving the discussion to a review makes sense
15:47:31 <carl_baldwin> johnbelamaric: Great.  Thanks for your work here.  I’m exciting to get this done.
15:47:39 <carl_baldwin> #topic l3 plugin for routervm/modular l3 router plugin
15:47:44 <carl_baldwin> yamahata: ping
15:47:59 <yamahata> carl_baldwin: pong
15:48:29 <yamahata> I'm planning to respin the spec this week. i.e. tomorrow
15:48:42 <yamahata> And upload WIP patch
15:48:43 <carl_baldwin> yamahata: great.
15:48:57 <yamahata> WIP = no test yet
15:49:09 <carl_baldwin> Do you have any discussion points to bring up?
15:49:29 <yamahata> nothing at this point.
15:49:41 <pc_m> yamahata: Link to spec, please?
15:50:11 <yamahata> https://review.openstack.org/#/c/105078/
15:50:14 <pc_m> Thanks!
15:50:51 <carl_baldwin> yamahata: Could you “Set the URL for this specification” in launchpad so that the specs are a bit easier to find from the blueprints?
15:51:46 <yamahata> carl_baldwin: done
15:52:27 <carl_baldwin> yamahata: Thank you.  I have subscribed to both specs and will watch them.
15:52:53 <carl_baldwin> #topic Open Discussion
15:54:36 <carl_baldwin> If there is nothing else, we’ll close the meeting for today.  Thanks everyone for your work.
15:54:44 <carl_baldwin> I hope that some of you can make it to the mid
15:54:48 <rossella_s> carl_baldwin: regarding the l2 agent improvements...who's gonna coordinate that?
15:54:50 <carl_baldwin> -cycle meetup.
15:55:17 <carl_baldwin> rossella_s: That is a good question.  It was not on the top of my mind.
15:56:12 <rossella_s> I imagine a design spec should be proposed, something similar to what you did for the l3 agent
15:56:57 <carl_baldwin> rossella_s: I guess we should get with armax and discuss that.  I’m trying to find the etherpad which I had up in a tab.
15:57:22 <rossella_s> https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
15:57:25 <rossella_s> this one?
15:57:36 <rossella_s> #link https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
15:57:43 <carl_baldwin> rossella_s: You beat me, yes that one.
15:58:22 <carl_baldwin> rossella_s: Your name is the first one I see on the etherpad.  ;)
15:58:33 <rossella_s> :D
15:59:13 <carl_baldwin> marios, Kevin, Manish, Terry, Eugene, Armando, Simeon are the others.
15:59:38 <rossella_s> yes, maybe we should discuss with those people and spit taks
15:59:43 <carl_baldwin> rossella_s: This meeting is about out of time.  We could discuss more in the neutron room.  Do you have suggestions for how to proceed?
15:59:44 <rossella_s> s/tasks/tasks
15:59:57 <rossella_s> it's ok, let's move to the neutron room
16:00:00 <carl_baldwin> #endmeeting