15:02:57 #startmeeting neutron_l3 15:02:58 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:01 The meeting name has been set to 'neutron_l3' 15:03:10 #topic Announcements 15:03:17 #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam 15:03:36 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 The mid-cycle has been announced but I think the date is still in question. 15:04:38 #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/050128.html 15:05:10 Here is the wiki: https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint 15:05:31 I plan to be there for either week. 15:05:43 #link https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint 15:06:10 Summit was great. 15:06:15 Any other announcements? 15:06:35 nothing from me 15:07:11 Okay. 15:07:32 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 #topic l3-high-availability 15:07:58 safchain: amuller: Anything new here? 15:09:06 #topic bgp-dynamic-routing 15:09:08 devvesa: ping 15:09:16 hi 15:09:29 I talked to a lot of people at the summit who are interested in this. 15:10:04 do they use case (or idea) fit with current spec? 15:10:26 Many of them, yes. This is outside of the BGPVPN crowd. 15:11:00 yes, it seems so. Every time I'm more conviced that we can find very few points in common with them 15:11:02 There is some interest for it with routing to IPv6 networks. 15:11:46 The use case is very specialized. 15:12:07 I see that the spec has a few minor comments. Will you have a chance to take a look at it? 15:12:13 Mathieu Rohon found some nits in current spec. I will push a new patch 15:13:00 yes, currently I'm caught in Midonet's CI because of our open source stuff 15:13:07 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 If I find a free hour I'll review 15:13:25 this week 15:13:37 uhm... maybe beginning of next :) 15:13:46 devvesa: I hope you can find that hour. 15:13:47 (just realised we live on Thursday) 15:14:10 These weeks do go by quickly. 15:14:23 #action devvesa to update the bgp spec 15:14:24 what we need after your approval 15:14:29 ? 15:14:47 devvesa: We need the Neutron drivers team to approve. 15:14:59 #action carl_baldwin will reach out to Neutron drivers team. 15:15:04 cool 15:15:04 devvesa: anything else? 15:15:10 nothing else. thanks 15:15:36 devvesa: Thank you. It was good to see you at the summit. 15:15:50 #topic L3 Agent Restructuring 15:16:13 I updated my spec and got a lot of feedback yesterday. I’m partially through addressing that feedback. 15:16:25 #link https://review.openstack.org/#/c/131535/ 15:16:38 * pc_m lots of good stuff in there 15:17:20 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 I wanted to ask if anyone read the comments around L132? 15:17:49 #link https://review.openstack.org/#/c/131535/2/specs/kilo/restructure-l3-agent.rst 15:18:15 yes 15:18:33 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 Thanks for all of your comments, btw. 15:19:19 I’m once again entertaining the idea of using inheritence for types of routers like DVR, HA, Legacy. 15:20:29 Any more thoughts? 15:20:32 Gut feel is that services seem like capabilities added (composition) for a router. 15:21:00 Router has a VPN capability, router has a FW capability. 15:21:27 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 :) 15:21:54 I’m entertaining the idea of using inheritence to create a DVRRouter, HARouter, etc. 15:21:56 maybe armando should also take a look? 15:22:20 oh, well, salvatore is there 15:22:31 Yes, I would welcome armax’s input here. 15:22:50 It is a bit early for him though since DST has ended for the year. :) 15:22:56 :) 15:23:01 * armax catching up 15:23:14 so a router that uses DVR and HA is going to be a DVRHARouter? 15:23:21 armax: no worries. 15:23:31 devvesa: I think that would follow, yes. 15:24:09 * carl_baldwin just realized that DVRRouter is redundant. 15:24:54 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 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 carl_baldwin: inheritance vs composition needs to be looked at especially when considering how much code can be reause 15:25:11 whereas HA it depends on user call 15:25:16 (just thinking loud) 15:27:24 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 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 However, igoring the agent configuration part, a DVR can be created much like an HA router. 15:28:46 devvesa: That is a point that I continue to consider. Thanks. 15:28:56 amuller: hi 15:29:04 carl_baldwin: Hey sorry I was interviewing someone 15:29:23 amuller: Looking for a new job? 15:29:31 * carl_baldwin is joking 15:29:34 The guy I was interviewing is =D 15:29:52 Are you? :) 15:30:09 amuller: We were just wrapping up the discussion on inheritence from the L3 agent spec. 15:30:20 I'll read the meeting notes later 15:30:34 I hope to hear your thoughts but I’ll give you a chance to catch up. 15:31:11 inheritence vs drivers for different router types? Let's decide that during implementation phase, imo 15:31:13 I think we’ll take the discussion to the review. 15:31:39 amuller: We may need the flexibility to do just that. 15:32:00 #topic neutron-ipam 15:32:17 We had a good discussion about IPAM at the design summit. 15:32:50 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 johnbelamaric: I was just noticing your comments on the review. 15:33:14 https://review.openstack.org/#/c/97967/35/specs/kilo/neutron-ipam.rst 15:33:25 agree that we need to cut the originally proposed interface way back 15:33:29 #link https://etherpad.openstack.org/p/neutron-ipam 15:34:18 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 agreed 15:34:36 johnbelamaric: I’d like the interface to be intuitive to use and review. 15:34:59 "minimal surface area" is the way Soheil put it yesterday :) 15:35:51 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 But, I think it should be enough to illustrate what I had in my mind. 15:36:23 #link http://paste.openstack.org/show/132513/ 15:36:32 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 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 johnbelamaric: It does know. L64. My thought was that the driver would be instantiated once for each scope. 15:37:21 i will do more of a thorough review today 15:37:28 yes 15:38:17 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 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 address_type is similar. They are orthogonal. Hence, the address_type argument no the same line. 15:38:54 yes, that makes sense. so, different scopes managed by different drivers or instances thereof 15:39:04 not sure why address type needs a separate driver instance 15:39:17 but i don't see a problem with it 15:39:23 johnbelamaric: Yes, I assumed that the driver can define its own configuration. 15:40:05 johnbelamaric: address_types are also orthogonal. Cluttering the rest of the interface with address_type parameters would less clean. 15:40:58 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 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 I’ll add you folks as reviewers when I have posted the spec. 15:41:27 ok, great. thanks 15:41:43 i will review your proposal closer today 15:41:55 johnbelamaric: Right. I imagine configuration will be done through config files. But, there may be some room to enhance this interface. 15:42:24 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 johnbelamaric: You may a point there. Let’s continue the discussion about this. 15:43:35 ok 15:43:51 Maybe I should post the base class as a review so that we can annotate it with discussion. 15:44:15 yes, i think that would be helpful 15:44:19 I was being a bit hasty yesterday when I threw it in pastebin. 15:44:40 #action carl_baldwin will post a review with http://paste.openstack.org/show/132513/ 15:44:52 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 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 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 great, thanks carl 15:46:21 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 ok, good 15:46:42 johnbelamaric: Thanks. 15:46:45 Anything else? 15:47:04 not right now on IPAM for me - moving the discussion to a review makes sense 15:47:31 johnbelamaric: Great. Thanks for your work here. I’m exciting to get this done. 15:47:39 #topic l3 plugin for routervm/modular l3 router plugin 15:47:44 yamahata: ping 15:47:59 carl_baldwin: pong 15:48:29 I'm planning to respin the spec this week. i.e. tomorrow 15:48:42 And upload WIP patch 15:48:43 yamahata: great. 15:48:57 WIP = no test yet 15:49:09 Do you have any discussion points to bring up? 15:49:29 nothing at this point. 15:49:41 yamahata: Link to spec, please? 15:50:11 https://review.openstack.org/#/c/105078/ 15:50:14 Thanks! 15:50:51 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 carl_baldwin: done 15:52:27 yamahata: Thank you. I have subscribed to both specs and will watch them. 15:52:53 #topic Open Discussion 15:54:36 If there is nothing else, we’ll close the meeting for today. Thanks everyone for your work. 15:54:44 I hope that some of you can make it to the mid 15:54:48 carl_baldwin: regarding the l2 agent improvements...who's gonna coordinate that? 15:54:50 -cycle meetup. 15:55:17 rossella_s: That is a good question. It was not on the top of my mind. 15:56:12 I imagine a design spec should be proposed, something similar to what you did for the l3 agent 15:56:57 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 https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt 15:57:25 this one? 15:57:36 #link https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt 15:57:43 rossella_s: You beat me, yes that one. 15:58:22 rossella_s: Your name is the first one I see on the etherpad. ;) 15:58:33 :D 15:59:13 marios, Kevin, Manish, Terry, Eugene, Armando, Simeon are the others. 15:59:38 yes, maybe we should discuss with those people and spit taks 15:59:43 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 s/tasks/tasks 15:59:57 it's ok, let's move to the neutron room 16:00:00 #endmeeting