15:01:09 <carl_baldwin> #startmeeting neutron_l3
15:01:09 <openstack> Meeting started Thu Apr 17 15:01:09 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:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:13 <openstack> The meeting name has been set to 'neutron_l3'
15:01:24 <carl_baldwin> #topic Announcements
15:01:30 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:01:41 <xuhanp> hello
15:01:47 <carl_baldwin> This week-end is the deadline to submit topics for the summit.
15:02:01 <carl_baldwin> #link http://summit.openstack.org/
15:02:38 <carl_baldwin> I will submit a couple of topics as soon as I get approval to do so.  ;)
15:03:13 <carl_baldwin> Any other announcements?
15:03:51 <carl_baldwin> #topic ML3 / L3 Vendor plugins
15:03:59 <carl_baldwin> As discussed in the Neutron meeting on Monday, this is added to today's agenda.
15:04:17 <carl_baldwin> I'm sure there are many thinking about this from different angles.
15:04:32 <carl_baldwin> I'd like to start by asking you all what you hope to get out of this discussion.
15:05:00 <carl_baldwin> For me, I would like to hear some concrete use cases for this feature.  To get my gears turning.
15:05:26 <carl_baldwin> I'd also like to know how we can use the time leading to the summit to prepare for a productive conversation.
15:05:27 <pcm__> I have some w/what I see with VPN
15:06:35 <pcm__> Big one is that currently, a vendor (or alternate service driver) has no way to do validation before info is persisted.
15:07:00 <pcm__> As a result, all that can be done is placing the resource in error state.
15:07:40 <carl_baldwin> I see that you've started a blueprint on that.
15:07:53 <pcm__> yes: https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation
15:08:03 <carl_baldwin> Are you planning to submit a blueprint specification to gerrit?
15:08:28 <pcm__> Yeah, just need to learn about what I need to do for that
15:08:42 <carl_baldwin> BTW, the summit discussion topic is here:
15:08:52 <carl_baldwin> #link http://summit.openstack.org/cfp/details/81
15:09:30 <carl_baldwin> pcm__: Yes, there is a new learning curve with the new process.  I know from experience.  ;)
15:10:01 <carl_baldwin> It is worth learning though.  I think the new process is a big improvement.
15:10:05 <pcm__> mestery: Will probably need some pointers on what to do there.
15:10:33 <mestery> pcm__: Sure! Look here for starters: https://wiki.openstack.org/wiki/Blueprints#Neutron
15:10:42 <pcm__> mestery: thanks
15:10:44 <mestery> pcm__: If you have questions, please reach out. This is new for all of us. :)
15:10:53 <pcm__> roger that
15:11:15 <carl_baldwin> pcm__: I also found that checking out the new repository and making sure that tox runs in the directory is a good start.  There is a nice read me and a template.
15:11:41 <pcm__> carl_baldwin: cool. I'll have to do that next.
15:12:39 <carl_baldwin> pcm__: cool.  Back to the blueprints.  I think I'd like to see a few concrete examples, like your VPN example, that lay down some motivation for the features.
15:13:10 <pcm__> So, in general, just trying to think of ways to fit vendor plugins in, as things are very centric to reference implementation.
15:13:33 <overlayer> I'm interested in the L3 vendor plugins,  could it be explored in such a way as to enable distant, legacy routers to act as a normal neutron router for virtual networks? For instance, this blueprint expands on that idea: https://blueprints.launchpad.net/neutron/+spec/provider-router
15:14:16 <carl_baldwin> Ultimately, we'll want a general framework that supports it but I always like to start with the concrete examples.
15:14:28 <overlayer> if that router could somehow be used as a vendor plugin, it would be awesome and better align with neutron's architecture
15:14:58 <mestery> overlayer: That's a very interesting use case, and I think it maps into what pcm__ is thinking here as well.
15:15:32 <Swami> How will this architecture fit into the distributed model.
15:15:55 <carl_baldwin> pcm__: overlayer:  That is the kind of content I would like to see in the blueprint.  A paragraph about how these blueprints fit together would be great.
15:16:09 <overlayer> the idea is that a (usually) physical router (at the other side of the internet) be used to route traffic from a virtual network to other networks (that may be physical), encapsulating the traffic that goes through the internet (as if the virtual network was directly connected)
15:17:01 <carl_baldwin> Swami: That is a great point as well.  We will soon have the distinction between services that can be distributed and those that cannot.
15:17:48 <Swami> carl: yes that would give a clear idea.
15:18:52 <carl_baldwin> overlayer: sounds like a vpn use case.  Is it different?
15:19:34 <overlayer> pcm__: carl_baldwin mestery, Yes, the provider-router BP has some similarities to VPN so some ideas could be discussed...
15:20:40 <overlayer> carl_baldwin: It is similar but aims at making legacy router connectivity to virtual networks as straightfoward as possible
15:21:06 <overlayer> in such a way that companies can migrate their legacy networks to the cloud as painlessly as possible
15:21:47 <AndChat|112404> Is it basically a way to integrate a physical router in the virtual topology?
15:22:54 <carl_baldwin> overlayer: What sort of encapsulation do you imagine between the cloud network and the "distant" router.  Are you thinking of connecting L2 segments between the two networks?  Or is this just L3 routing to the new cloud networks?
15:22:57 <overlayer> I have a feeling it doesn't fit very well in neutron's path right now, and some use cases or concepts are overlapping or at the wrong place... but if the end result could be made possible, it would be awesome
15:23:49 <mestery> AndChat|112404: That's what I was thinking this was. overlayer, is this correct?
15:24:09 <carl_baldwin> pcm__: overlayer:  Could you take action items to document the use cases that you have in mind?  Either wiki or blueprint is fine but please link to them from the L3 sub team wiki page.
15:24:54 <overlayer> carl_baldwin: as of now, I'm thinking of the distant router establishing a tunnel to neutron (to each of the VMs) by automatic configuration made by neutron
15:25:11 <pcm__> carl_baldwin: Sure. I have some use case info, but will add more.
15:25:12 <overlayer> carl_baldwin: the rest is routing (between virtual networks), made by that same distant router
15:25:36 <carl_baldwin> overlayer: A simple diagram might help to communicate it clearly.
15:26:04 <carl_baldwin> #action pcm__ document known use cases.
15:26:21 <overlayer> I have one in google docs
15:26:22 <overlayer> page 4
15:26:45 <carl_baldwin> overlayer: is that linked from the blueprint?
15:26:59 <overlayer> I have proposed a DPR agent, which is basically the same as the L3 agent but encapsulates a distant router instead of a virtual one
15:27:24 <overlayer> carl_baldwin: yes
15:27:32 <pcm__> mestery: Should I put the use cases in the BP spec?
15:28:00 <pcm__> (in gerrit)
15:28:42 <carl_baldwin> overlayer: Thanks.
15:29:01 <mestery> pcm__: I think that's the best place for them.
15:29:49 <carl_baldwin> Let's move on.  I need to review these blueprints further and I'm sure others do as well.  pcm__ I'm looking forward to seeing the specifications even if it is just a rough start.
15:30:19 <carl_baldwin> #topic l3-high-availability
15:30:21 <pcm__> carl_baldwin: yeah, me too :)
15:30:50 <carl_baldwin> pcm__: I think that having them in place will make for a better discussion at summit.
15:30:54 <carl_baldwin> safchain: Any updates?
15:31:00 <safchain> safchain, Hi all
15:31:37 <safchain> submitted a new patch set of the DB side in order to address some comments
15:32:23 <safchain> reviewed the l3 BP part of DVR to understand how the central agent will work
15:32:26 <carl_baldwin> I will add that to my review cue.  I think that many of us may be able to find some time to review again now that Icehouse is released and summit topics are almost submitted.
15:32:38 <safchain> made some comment/question on the gdoc
15:32:57 <safchain> carl_baldwin, great
15:33:10 <carl_baldwin> safchain: Thanks for reviewing DVR.  That is a pretty hot item for Juno.
15:33:31 <safchain> carl_baldwin, yes sure
15:34:08 <safchain> carl_baldwin, that's all for mr
15:34:09 <safchain> me
15:34:12 <carl_baldwin> I'll encourage others to review l3-high-availability and neutron-ovs-dvr now that we're in to Juno.  We would like both to land early in the cycle.
15:34:18 <carl_baldwin> Thanks, safchain
15:34:19 <Swami> safchain: one other thing that we wanted to make sure, is that the vrrp code can be utilized for the Service node in dvr.
15:34:34 <carl_baldwin> #topic bgp-dynamic-routing
15:34:41 <carl_baldwin> nextone92: hi
15:34:53 <nextone92> Hi Carl!
15:34:54 <safchain> Swami, yes sure, let's talk about that after
15:34:54 <carl_baldwin> I see that you've submitted a summit topic.
15:35:07 <nextone92> Yes: http://summit.openstack.org/cfp/details/283
15:35:22 <nextone92> The blueprint is a gdoc at the moment
15:36:04 <carl_baldwin> No worries.  It will take us all a little time to convert to restructured text and merge with the template.
15:36:22 <carl_baldwin> nextone92: Anything to highlight?
15:36:48 <nextone92> Not at the moment, I didn't see any feedback from the document or on the mailing list
15:37:18 <overlayer> I have read the blueprint, and have some feedback
15:37:47 <nextone92> Great! Thank you overlayer
15:37:51 <carl_baldwin> overlayer: Feel free to provide that feedback on the blueprint or ask on the ML.
15:38:05 <carl_baldwin> #topic rootwrap-daemon-mode
15:38:18 <overlayer> why only BGP? did you think of a more generic way that can encompass different protocols while keeping the use cases intact?
15:38:26 <carl_baldwin> #undo
15:38:27 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x389cd50>
15:38:46 <overlayer> carl_baldwin: on the blueprint, the doc? or here too?
15:39:19 <overlayer> carl_baldwin: got it
15:39:28 <carl_baldwin> overlayer: It is intended that this be done with a generic interface.  However, BGP is the implementation that seems to have the most interest for a first implementation.
15:39:37 <carl_baldwin> overlayer: In the doc would be great.
15:39:57 <overlayer> carl_baldwin: thank you
15:40:07 <carl_baldwin> overlayer: yw
15:40:08 <carl_baldwin> #topic rootwrap-daemon-mode
15:40:21 <carl_baldwin> ago, YorikSar: Are you around?
15:41:11 <carl_baldwin> We'll continue discussion in the reviews.
15:41:23 <carl_baldwin> #link https://review.openstack.org/#/q/status:open+branch:master+topic:bp/rootwrap-daemon-mode,n,z
15:41:42 <carl_baldwin> #topic neutron-ovs-dvr
15:41:49 <Swami> carl: hi
15:41:55 <carl_baldwin> Swami: hi.  I wanted to make sure that you had some meeting time left to discuss.
15:42:00 <Swami> DVR Progress update.
15:42:14 <Swami> East-West completed.
15:42:30 <carl_baldwin> Excellent!
15:42:35 <Swami> FIPs completed for the North-South and working on the Service node right now.
15:42:46 <carl_baldwin> I have started my review.  I encourage all to review.
15:42:49 <Swami> L2 Agent code was posted for review.
15:42:57 <carl_baldwin> #link https://review.openstack.org/#/q/topic:bp/neutron-ovs-dvr,n,z
15:42:58 <Swami> It is good that we are getting early review.
15:43:14 <carl_baldwin> ^ This is a great link to track DVR review progress.  Bookmark it!  :)
15:43:21 <Swami> We are trying to address the reviews while we are working on the other aspects of the DVR.
15:43:39 <mestery> +1 to the link carl_baldwin!
15:43:47 <Swami> In the coming week we will be posting the remaining code patches for L3 Agent and for the Scheduler.
15:43:48 <carl_baldwin> Swami: I hope that the feedback has been constructive.
15:44:03 <Swami> carl: Sure it is of great use for us.
15:44:26 <mestery> Swami carl_baldwin: Per the new BP process, it would be great to get BPs into neutron-specs for review as well!
15:44:30 <Swami> Especially since we are targeting the DVR for the Juno milestone 1 it would be of great help if we have early feedback.
15:44:38 <carl_baldwin> A word to reviewers.  In order to not bog down the development process.  While the patches are WIP maybe we can stay away from nits and focus on the high level implementation details.
15:44:38 <mestery> I expect those to pass pretty quickly, but it's the new process and all, so I encourage that too.
15:45:09 <mestery> Swami: Are the patches in a state where people can test them out? I'd like to try them soon.
15:45:13 <Swami> mestery: Thanks for reminding me. I was about to ask, since we have already reviewed the blueprint should be again follow the new model to push our blueprint
15:45:40 <Swami> mestery: Yes it should be in a state to test. These are internal working code.
15:45:41 <mestery> Swami: Yes, the new BP process works such that features which miss a release need to re-propose at the start of the next cycle. Nova is doing the same, so we're consistent there.
15:45:51 <mestery> Swami: Great! I will go ahead and try them out, thanks!
15:46:01 <Swami> mestery: Thanks for confirmation. I will do it asap.
15:46:15 <mestery> Swami: Thanks!
15:46:28 <Swami> mestery: You may have to wait for the other patches that are requirement for the complete flow.
15:46:45 <mestery> Swami: OK, got it, I'll keep on the lookout on gerrit. ;)
15:47:01 <Swami> That's all I have from the DVR side.
15:47:22 <carl_baldwin> Swami: Thanks for the update.  Great progress.
15:47:50 <carl_baldwin> #topic Multiple Subnets on External Network
15:48:38 <carl_baldwin> I introduced this topic last week because I was unable to get multiple floating ip subnets to work on an external network.
15:49:02 <Swami> carl: For the multiple subnets on External network, also we had an issue with the DVR with the latest code.
15:49:28 <Swami> Since there was a change in the bridge mapping behaviour for the multiple subnets for Extenal network.
15:49:32 <carl_baldwin> I played with it a bit and found that it actually isn't as broken as I thought.
15:50:07 <carl_baldwin> Swami: I know that you were playing around with multiple external networks.  I want to make sure that we're talking about the same thing.
15:50:14 <Swami> We are still looking into it to see how the DVR rules can work in a multiple subnet scenario.
15:50:45 <carl_baldwin> There are multiple external networks, supported by provider networks.  Then, there are multiple subnets on a single external network.
15:51:08 <carl_baldwin> Swami: Can you confirm which one specifically you are talking about just to be clear?
15:51:46 <Swami> carl: You are right, I am talking about the multiple external networks and you are talking about the multiple subnets on single network.
15:52:00 <carl_baldwin> I had a feeling.  ;)
15:52:54 <carl_baldwin> I actually was able to get multiple floating ip subnets to work on a single external network in devstack with only a couple of little hacks.  I plan to file a bug and post a patch soon.
15:53:52 <carl_baldwin> I was actually very pleased.  I was worried it was going to be a lot of work and require a new blueprint and all that.  But I found that the code is pretty much all there, it just needs a couple of little fixes.
15:54:07 <carl_baldwin> Anyway, that is my report an that.
15:54:31 <carl_baldwin> #topic Open Discussion
15:55:10 <pcm__> carl_baldwin:  Can you post link for L3 team sub page?
15:55:27 <carl_baldwin> pcm__: Sure thing
15:55:30 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:55:33 <pcm__> carl_baldwin: thanks!
15:57:30 <carl_baldwin> Thank you all for your great work.  I look forward to seeing progress in all of these areas.
15:58:14 <carl_baldwin> Until next week.
15:58:26 <safchain> carl_baldwin, thx
15:58:36 <carl_baldwin> #endmeeting