15:00:20 #startmeeting neutron_dvr 15:00:20 Meeting started Wed May 4 15:00:20 2016 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:23 The meeting name has been set to 'neutron_dvr' 15:00:38 #chair Swami 15:00:39 Current chairs: Swami haleyb 15:01:12 #topic Announcements 15:01:54 Hope everyone had a good week at Summit and got home safely 15:02:26 Now we have to get back to work :) 15:02:28 Yep 15:02:34 #topic Bugs 15:02:55 haleyb: there are no new bugs this week. 15:03:16 haleyb: There was just one RFE that was filed this week for the fast path exit. 15:03:32 #link https://bugs.launchpad.net/neutron/+bug/1577488 15:03:34 Launchpad bug 1577488 in neutron "[RFE]"Fast exit" for compute node egress flows when using DVR" [Wishlist,Triaged] 15:04:22 But we still have a bunch of bugs that we need to close. 15:04:38 yes, there are still many open patches 15:05:15 haleyb: I had a question on this bug 15:05:35 #link https://review.openstack.org/#/c/306065/ 15:06:23 There was a comment from Hon Hui Xiao on this patch regarding a chance of regression. 15:06:35 yes, and i see it passed jenkins this time :-/ 15:07:09 What do you think, since that is being handled in another patch, I don't want to include it here. Do you think we should also add some check in here for the delete function to check for real existence of the namespace. 15:07:55 does the other patch do an "exists" first? i think that's the case 15:08:25 haleyb: Yes in the other patch on the super class delete, we are checking for the device exist. 15:08:49 #link https://review.openstack.org/#/c/300358/ 15:10:15 Swami: does the first patch actually open the possibility of that delete() failure? 15:10:38 hmm, maybe it does 15:10:41 I am not sure, at this point who calls that delete even. 15:11:57 May be when the router is removed, this delete in dvr_edge_router is called. 15:12:33 I guess we should try and test that path then, since there's no flag indicating we actually created the namespace, just the struct 15:12:51 If it makes sense, we can add the 'exists' check in this patch and so it can be backported without causing any regression. 15:13:07 yes, i was thinking the same thing 15:14:00 haleyb: ok let me then add the exists check to the patch. 15:15:28 It's almost like the Namespace class should have a flag to show we created the namespace, but that's not perfect either i think 15:16:28 yes, I always think it is better to check the system rather then the object, because the namespace in the system can be deleted directly. 15:16:30 i.e. self.created or self.exists 15:17:02 right, users with sudo or that cleanup script 15:17:12 haleyb: yes 15:17:31 haleyb: so it is better to check rather then depending on the flag that we update while creating. 15:19:49 sorry got disconnected 15:20:10 np 15:20:28 The next one in the list is 15:20:29 had a question regarding https://review.openstack.org/#/c/308068/5/neutron/agent/l3/dvr_local_router.py 15:20:47 https://review.openstack.org/#/c/308068/5 15:20:55 yes I am coming to that patch. 15:21:00 Is it safe adding those static routes everywhere? 15:21:12 oh, i thought we already did, but later is fine 15:21:34 It should not cause any issues. 15:21:49 Other than raising a runtime error when the interfaces are not there. 15:22:08 So the routes will not be even added there if the interfaces are not there. 15:22:24 ah, i'm now remembering this conversation 15:22:31 The issue here is you might pollute the logs with the runtime error. 15:23:02 So eventually we might have to check the cidr of the next hop and only add routes that are applicable to the namespace. 15:23:31 I had a patch that was doing this, but carl_baldwin suggested not to complicate and add the routes to all namespaces. 15:23:56 So we should probably revisit later and fix this to be specific to the namespace. 15:24:14 If we feel that raising a runtime error is an issue. 15:24:27 yeah, maybe another way is to check the interface exists (if we have that info) 15:24:52 haleyb: yes 15:24:59 but i'm fine leaving as-is for now 15:25:10 haleyb: #agreed 15:27:13 continue with the other bugs/patches 15:27:20 yes 15:27:41 #link https://review.openstack.org/#/c/300268/ 15:28:10 This patch I still have a failure in the functional test that I am trying to fix it. I am not sure what is happening. 15:28:48 When I debug, it is calling the right l3_notifier, but it fails the test case. Something might be messy with the mock. 15:29:04 If you get a chance can you take a look at it. 15:29:21 ok 15:30:15 The next one in the list is 15:30:42 #link https://review.openstack.org/#/c/289172/ 15:31:31 haleyb: one question on this patch. 15:32:20 since carl_baldwin is reverting a patch that went it to fix this issue, should I have my patch as a dependent of the revert patch or can it be alone. 15:32:46 #link https://review.openstack.org/#/c/301348/ 15:33:52 Swami_: I think xiaohhui might have upload a different patch that doesn't revert the entire thing. I can look in a bit. 15:34:05 carl_baldwin: ok thanks 15:34:13 carl_baldwin: do you have the link for the patch. 15:34:31 Swami_: Not at the moment but I will look when I get a chance. 15:34:41 carl_baldwin: thanks no problem. 15:34:44 right, that was a partial revert 15:35:29 ok 15:36:09 haleyb: there is another patch regarding the floatingip and allowed_address_pair for delayed fip. 15:36:28 #link https://review.openstack.org/#/c/304905/ 15:37:17 i'll take a look, but think you addressed my comments 15:37:19 haleyb: Lbaas folks did test this patch and had some concern regarding the check that we make for ACTIVE ports. 15:37:29 haleyb: yes I have addressed your comments. 15:38:00 haleyb: it seems thier use case is both the VM ports will always be ACTIVE irrespective of who is MASTER or SLAVE. 15:38:42 Swami_: so will it need another update? 15:39:07 haleyb:no we are going to have another meeting today with the lbaas folks, and I will update after it if required. 15:39:34 haleyb: I need to drop off, since I have another meeting, can you continue. That's all I had for bugs. 15:40:22 bye 15:40:23 * haleyb wonders if talking to himself for 20 minutes is useful :) 15:41:53 If noone else is listening I will just end the meeting and resume next week 15:42:00 I am : ) 15:43:04 fitoduarte: hi adolfo 15:45:23 sorry I am late again, but just want to make sure the following was mentioned: 15:45:26 https://review.openstack.org/#/c/307526/ 15:45:39 it needs some review love 15:46:44 ok, i hadn't seen that one. Is an HA "expert" looking? 15:48:06 Not sure, i can add amuller and johns to reviwers. 15:48:37 yeah, especially adding all those new tests 15:48:51 will do tx 15:50:07 anyone have other bugs/patches to discuss ? 15:50:46 back in 15:51:14 I don't have any at this point 15:51:24 ok 15:51:41 #topic Gate failures 15:52:10 The multi-node jobs seem to be trending upwards, and i've seen "qrouter namespace doesn't exist" errors this week 15:52:15 haleyb: I did see that the multinode job failures were high last week. 15:52:38 haleyb: Is that seen just in the functional tests, or all tempest tests. 15:53:20 i'm looking at tempest in https://goo.gl/L1WODG haven't got to grafana yet 15:54:06 haleyb: for the multinode I suspect that there is some infra issue, since both the neutron multinode and dvr multinode are failing. 15:55:01 dvr is even below the plain multinode 15:55:47 in the check queue 15:55:53 haleyb: you mean dvr has more failures then the plain multinode 15:56:12 no, dvr has less, let's make it voting! :) 15:56:18 haleyb, 15:56:22 haleyb: sure 15:56:44 haleyb: do you know of any tempest folks that can help us in writing the scenarion test for the live migration. 15:57:23 haleyb: I am not a tempest expert, since that is dependency for the nova live migration patch to go in. 15:57:31 i don't know any tempest folks 15:57:52 yes, is there anyone else lurking that wants to help with this? 15:58:09 haleyb: just to speed up the process. 15:58:33 haleyb: I don't know 15:59:27 Swami_: maybe we can mark it "low hanging fruit" :) 15:59:35 haleyb: good idea 15:59:44 haleyb: I like your proposal 15:59:48 We're about out of time, so will pick this up again next week 16:00:12 #endmeeting