15:02:00 <carl_baldwin> #startmeeting neutron_l3
15:02:01 <openstack> Meeting started Thu Aug 21 15:02:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:05 <openstack> The meeting name has been set to 'neutron_l3'
15:02:10 <Rajeev> carl_baldwin: Hi
15:02:16 <carl_baldwin> #topic Announcements
15:02:23 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:02:33 <carl_baldwin> Feature Proposal Freeze is August 21st (today)
15:02:50 <carl_baldwin> Patches for new features posted after today will be automatically deferred.
15:03:34 <carl_baldwin> Juno-3 is September 4th.  That is just two short weeks away.
15:04:04 <carl_baldwin> Reviewers will be getting in to even more of a crunch as that approaches.
15:04:12 <carl_baldwin> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
15:04:56 <carl_baldwin> #topic Bugs
15:05:31 <carl_baldwin> I think the bugs have been kept under control.  There are a couple I’d like to get in to Juno.
15:05:40 <carl_baldwin> bug 1334926
15:05:53 * pcm_ sorry late
15:05:55 <carl_baldwin> bug #1335375
15:06:11 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1334926
15:06:17 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1335375
15:06:35 <carl_baldwin> I think that is all for the general bugs.
15:06:52 <carl_baldwin> #topic neutron-ovs-dvr
15:07:19 <carl_baldwin> Swami: ping
15:07:37 <carl_baldwin> I don’t see Swami around.  Does anyone else have a report for DVR?
15:07:59 <Rajeev> Mostly working through bugs
15:08:41 <mrsmith> I made good progress on migration yesterday
15:08:49 <mrsmith> I should post an update to the patch today
15:08:59 <Rajeev> Initiated design discussions with FWaaS team
15:09:06 <mrsmith> there are dependencies with the SNAT bugs however
15:09:36 <mrsmith> I merged the existing SNAT fix patch into my local migration patch
15:09:56 <carl_baldwin> mrsmith: merged?  Or did you rebase yours to it?
15:10:10 <mrsmith> hand merged
15:10:17 <mrsmith> as a prototype
15:10:38 <mrsmith> so we may want to consider making the migration patch dependent in gerrit for the snat fixes
15:10:53 <mrsmith> or just make sure the snat patch merges soon
15:11:02 <carl_baldwin> mrsmith: That will be better in the long run.
15:11:49 <mrsmith> I have updates to the snat patch also
15:11:58 <mrsmith> better handling for subnets
15:12:05 <mrsmith> in the 'do vms exist' method
15:12:06 <carl_baldwin> We have 19 bugs listed in the backlog.  Most are medium importance so I’m not too concerned about that.  But, I find it harder to keep up with the reviews because it is hard to tell when is ready for review.
15:12:29 <mrsmith> true
15:12:56 <mrsmith> in my opinion the snat and migration patches weren't ready *yet* but I think they will be on the next revs
15:13:14 <mrsmith> they both need more UTs also
15:14:10 <carl_baldwin> mrsmith: okay.
15:15:31 <carl_baldwin> mrsmith: Swami: Rajeev: viveknarasimhan: Please don’t hesitate to ping me when you feel a patch is ready for review.
15:15:55 <mrsmith> thanks. sounds good.
15:16:09 <carl_baldwin> There is one High Importance bug that does not have an owner.
15:16:26 <amuller> carl_baldwin: Can you share your search query?
15:16:36 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1358554
15:16:44 <carl_baldwin> amuller: The query for bugs?
15:16:49 <amuller> yeah
15:17:11 <carl_baldwin> I have two that are linked from here:  https://wiki.openstack.org/wiki/Neutron/DVR/HowTo#DVR_Backlog
15:17:23 <amuller> thanks
15:17:56 <carl_baldwin> amuller: glad to help.
15:19:16 <carl_baldwin> I will find someone to drive bug 1358554
15:20:09 <carl_baldwin> #action carl_baldwin will find owner for bug 1358554
15:20:13 <rossella_s> carl_baldwin: I can give it a try
15:20:14 <carl_baldwin> Anything else on DVR?
15:20:35 <rossella_s> carl_baldwin: will probably need some ramp up time, don't know the code very well
15:20:57 <Rajeev> for 1358718
15:20:59 <carl_baldwin> rossella_s: Are you familiar with how the dvr experimental job has evolved since July?
15:22:11 <rossella_s> carl_baldwin: to be honest not very much...but I always wanted to catch up and I have some time now...anyway if somebody with more experience is willing to take it, please go on
15:22:51 <carl_baldwin> rossella_s: I can catch you up a little after the meeting since we’ll be chatting anyway.
15:23:02 * carl_baldwin goes to look at
15:23:05 <rossella_s> carl_baldwin: great, thanks!
15:23:09 * carl_baldwin 1358718
15:23:54 <carl_baldwin> Rajeev: ?
15:24:10 <Rajeev> https://bugs.launchpad.net/neutron/+bug/1358718
15:24:39 <Rajeev> is this required for juno-3 ?
15:25:41 <carl_baldwin> Rajeev: It is marked Medium so technically no.  The Highs should be worked down first.
15:25:53 <Rajeev> agreed.
15:26:18 <Swami> hi
15:26:25 <Swami> sorry I am late.
15:26:27 <carl_baldwin> Swami: hi
15:27:32 <carl_baldwin> With that said, I’d like very much to wittle down the DVR backlog.  The number of Mediums is growing steadily.
15:27:39 <carl_baldwin> Swami: Anything to report?
15:27:48 <Swami> nothing to add at this time.
15:28:09 <Rajeev> carl_baldwin: can we chat later on https://bugs.launchpad.net/neutron/+bug/1335375 you mentioned earlier
15:28:22 <amuller> carl_baldwin: Swami: I'd love to get a decision down on the CLI patches for DVR
15:28:31 <amuller> Sort it out... We can talk about it after the meeting
15:28:57 <Swami> amuller: sure,
15:29:51 <carl_baldwin> Rajeev: yes, we can chat.  Finding me a bit later today.
15:30:39 <carl_baldwin> Anything else to discuss?
15:31:06 <carl_baldwin> #topic l3-high-availability
15:31:12 <carl_baldwin> amuller: safchain: hi
15:31:35 <amuller> Sylvain is on vacation
15:31:46 <amuller> I brushed up the server side patches since last week
15:32:18 <amuller> The scheduler patch is the weakest in the chain... There's a DB query there that's untested and I wouldn't be surprised if it's wrong
15:32:24 <amuller> The rest of the patches are better
15:32:35 <carl_baldwin> amuller: I think I saw that DB query.
15:32:37 <carl_baldwin> ;)
15:32:39 <amuller> We need reviews, I'll iterate fast and hopefully we'll be able to merge the feature
15:33:03 <amuller> I pushed a bunch of patches for another feature to observe the freeze today, I'm back on L3 HA now
15:34:46 <carl_baldwin> I’ll watch for you to address feedback.
15:34:51 <amuller> I will
15:34:55 <carl_baldwin> amuller: Do we need to chat about the DVR integration?
15:34:59 <amuller> You might force me to work on Friday =D
15:35:21 <amuller> carl_baldwin: I don't have any knowledge yet to contribute on that front sadly
15:35:26 <amuller> But I will by early next week
15:35:40 <carl_baldwin> I see two issues (there may be more)
15:36:03 <carl_baldwin> First is that the scheduler seems to be written for one or the other and not both.
15:36:11 <amuller> right
15:36:35 <carl_baldwin> Second may be a datapath issue since the snat namespace uses a second port that is not the gateway port.
15:37:28 <amuller> I'll have to look in to that
15:38:01 <carl_baldwin> So, feature freeze is two weeks out which concerns me a lot at this point.
15:38:13 <amuller> Yeah I have a bunch of new grey hair now
15:38:53 <mrsmith> carl_baldwin: the second port for snat - do you mean the internal port?
15:39:02 <carl_baldwin> mrsmith: yes.
15:39:08 <mrsmith> k
15:39:35 <carl_baldwin> vrrp would have to work on that port and not the internal gateway port.
15:39:48 <carl_baldwin> I shouldn’t have called it a gateway port.  ;)
15:40:11 <carl_baldwin> I mean the internal port that is the gateway for internal traffic.
15:40:48 <carl_baldwin> amuller: Let’s talk a little more about this soon when you’ve had a chance to think it over.
15:40:54 <amuller> Will do
15:41:05 <carl_baldwin> Meanwhile, I’ll move on the the agent side reviews.
15:41:45 <amuller> The l3 functional test is failing because of a gate configuration issue, there's patches by Maru to fix that
15:41:49 <amuller> it works locally
15:42:31 <amuller> And the agent-side patch that adds HA capabilities adds a new functional test for HA routers, which suffers from the same issue
15:42:51 <carl_baldwin> amuller: do you have links to those patches by marun ?
15:43:17 <amuller> in Neutron: https://review.openstack.org/#/c/114717/
15:43:27 <amuller> in infra: https://review.openstack.org/#/c/114416/
15:44:12 <carl_baldwin> Thanks, I will review.
15:44:18 <carl_baldwin> amuller: Anything else to discuss?
15:44:24 <amuller> Nay
15:44:31 <amuller> Thanks for your time Carl
15:45:25 <carl_baldwin> amuller: thank you.
15:45:38 <carl_baldwin> #topic bgp-dynamic-routing
15:45:44 <carl_baldwin> devvesa: Hi
15:45:47 <devvesa> hi
15:46:00 <carl_baldwin> I see you’ve been posting code.
15:46:22 <carl_baldwin> I plan to start reviewing it today.
15:46:23 <devvesa> yes, I've splitted the code in three patches
15:46:27 <devvesa> great!
15:46:45 <devvesa> i've edited the wiki subteam page with the links to the reviews
15:47:02 <carl_baldwin> How much have you been able to get working in your testing?
15:47:16 <carl_baldwin> devvesa: Thanks for the links.  I’ll go there to start.
15:47:41 <devvesa> extension and database mixin is fully tested
15:48:04 <carl_baldwin> Great.
15:48:18 <devvesa> i've been testing the agent with a remote quagga exchanging routes , and it works
15:48:41 <carl_baldwin> Did the bgp speakers comparison discussion conclude?  I’m sorry I’ve been out in DVR/HA land for a long time.
15:48:41 <devvesa> i need to spend more time testing more complex scenarios like two agents working in HA
15:49:05 <devvesa> well, I've just used Ryu because the api is clean and it has basic features
15:49:30 <carl_baldwin> #link https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison
15:49:36 <carl_baldwin> Ryu does look like a stand-out.
15:49:46 <carl_baldwin> How is the ryu code delivered?
15:50:00 <devvesa> installing from pypi
15:50:13 <carl_baldwin> Okay, that should be good.
15:50:31 <devvesa> and i like how it exchanges routes without touching the routing table of the agent's machine
15:50:47 <carl_baldwin> devvesa: sounds like you’ve done a lot.
15:51:03 <carl_baldwin> devvesa: I agree.  When I was playing around with quagga, that was a pain.
15:51:13 <carl_baldwin> This sounds like just what we need.
15:51:19 <amuller> devvesa: I think a 'how to test' wiki page but would really helpful
15:51:38 <devvesa> amuller: ok! I'll do
15:51:50 <carl_baldwin> amuller: +1
15:52:05 <carl_baldwin> devvesa: great.
15:52:06 <devvesa> #action devvesa write a wiki page about dynamic routing and test
15:52:36 <devvesa> amuller: don't expect a blog post like yours :)
15:53:14 <amuller> I'd appreciate something shorter hehe
15:53:32 <carl_baldwin> #action carl_baldwin will review BGP patches
15:53:34 <devvesa> don't worry about this! :D
15:53:50 <carl_baldwin> devvesa: anything more?
15:54:22 <devvesa> just a couple of comments, I don't know if you will be agree:
15:54:50 <devvesa> 1. as I told you, I've tried to simplify the spec doing less exposed endpoints
15:55:14 <devvesa> if you are not agree I have the 'extended version' :)
15:55:19 <carl_baldwin> Yes, I think #1 should be fine as we discussed.
15:55:46 <devvesa> and 2. the discovered routes are applied over router's static routes
15:56:22 <devvesa> but static routes are applied as a whole, so once you associate a router to a routing instance, it will override any routes
15:56:30 <devvesa> you have previously
15:56:47 <devvesa> I don't know if we can live with this
15:57:13 <carl_baldwin> So, using extraroutes and dynamic routes is mutually exclusive?
15:57:25 <devvesa> yes
15:57:54 <devvesa> so you can modify extra routes from the API, but the periodic task that check discovered routes will override it
15:58:13 <devvesa> only in the router you have associated
15:58:22 <devvesa> for dynamic routing
15:58:25 <carl_baldwin> I see.
15:59:21 <devvesa> maybe adding a new attribute in the extraroutes entity with the source that added it (static or dynamic)
15:59:24 <carl_baldwin> I might have to think about that.  My initial reaction is that it may be acceptible.  However, I wonder if some API tweak to detect and raise an error in the event that both are applied to a router.
15:59:24 <devvesa> would be enough
15:59:43 <devvesa> but I have not done this part
16:00:18 <carl_baldwin> Is this a problem if dynamic routing is turned on but a router does not learn routes.  Only advertises routes?
16:00:37 <devvesa> you can do it, sure
16:00:52 <carl_baldwin> devvesa: Let me think on it while I review the code.
16:00:54 <carl_baldwin> We’re out of time.
16:01:02 <devvesa> ok, thanks carl
16:01:11 <carl_baldwin> Bye everyone.  Thanks for all your work.
16:01:14 <carl_baldwin> #endmeeting