17:47:51 #startmeeting Networking FWaaS 17:47:51 Meeting started Wed Sep 3 17:47:51 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:47:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:47:56 The meeting name has been set to 'networking_fwaas' 17:49:11 thanks all for joining earlier 17:49:31 it will help to have the extra time to discuss the FWaaS/DVR issue at hand 17:49:46 first lets quickly get the other items out of the way 17:50:09 #topic Bugs 17:50:11 enikanorov__: hi 17:50:24 hi 17:51:05 #link https://bugs.launchpad.net/neutron/+bug/1314313 was upgraded in prirority from low to medium 17:51:21 and i wanted to check why since we have only since this in the experimental dvr gate 17:51:22 sorry, no update from my side, i didn't have a chance to look closer yet 17:51:51 enikanorov__: per our discussion during the neutron IRC meeting i think you confirmed that this was only in the DVR experimental gate 17:52:06 yes, that's correct 17:52:13 enikanorov__: if so, can we revert this to a the lower priority? 17:52:35 ok. i just thought that eventually dvr mode will be defaiult 17:52:41 hence 'medium' 17:53:59 enikanorov__: i think we should raise the priority once that happens 17:54:26 agree 17:54:33 enikanorov__: and like we mentioned the tempest test merge will most likely fix this in the DVR gate as well 17:55:11 enikanorov__: so hopefully we will be good by then 17:55:34 enikanorov__: thanks, if you can get a chance, please deliberate on the priority of that bug 17:55:47 SridarK: badveli: any other critical bugs to track? 17:55:50 ok, i will 17:55:54 i dont see in the bug lists 17:56:00 enikanorov__: thanks for your time 17:56:14 SumitNaiksatam: i don't think so - also i have not had a chance to scrub 17:56:24 sorry 17:56:35 just came back 17:57:10 badveli: any of the untriaged bugs have anything critical? in case you got a chance to check? 17:57:34 okay probably not 17:57:38 lets move on 17:57:43 #topic Service Objects 17:57:47 i did not check lately, but i think preeti fix 17:58:03 #undo 17:58:04 Removing item from minutes: 17:58:31 badveli: i dont think that is a critical priority issue is it? 17:58:53 no not critical 17:59:05 badveli: that has been in review for a while: #link https://review.openstack.org/108952 17:59:14 if thats the one you are referring to 17:59:16 ok moving on 17:59:23 : #topic Service Objects 18:00:25 thanks sumit, yes it was 18:00:30 #link https://review.openstack.org/106274 was -2’ed 18:01:08 badveli and the team were very diligent in pursuing this 18:01:40 thanks sumit, but not able to get any response 18:02:06 the blue print was been reviewed 18:02:07 anyone have any thoughts on this or would like to discuss? 18:02:51 i am not sure what is the process 18:03:25 the API changes are reviewed as part of the BP 18:03:41 badveli: true 18:03:46 badveli: +1 18:03:53 i am not able to understand if there is any other process to make people aware of it 18:04:40 suddenly if we say the API changes are not reviewed i am confused 18:04:43 we also first introduced this in Icehouse 18:04:55 yes, this has been quite a while 18:05:02 and then it was brought up during the Juno design summit review 18:05:45 we have also been discussing on a weekly basis in the fwaas meetings 18:06:13 thanks sumit for tracking this 18:06:30 but unfortunately my bad luck 18:06:31 i guess the only other thing left to do is to broadcast this to the ML regularly 18:07:11 although I am not sure that it is the required procedure for every new API 18:07:17 SumitNaiksatam: perhaps we should also bring this up at the summit - in terms of formalizing the API review process 18:07:21 anyway, but does not hurt 18:07:22 yes, this is what confusing me 18:07:36 if it involves something beyond a spec review 18:07:36 SridarK: sure 18:07:45 SridarK: agree 18:07:53 perhaps it should be documented 18:08:15 i noticed that Swami joined 18:08:23 #topic FWaaS DVR support 18:08:36 SridarK: go ahead 18:08:45 SumitNaiksatam: thanks 18:08:48 any developments 18:08:49 Swami: hi 18:08:58 SridarK: hi 18:09:10 SumitNaiksatam: yes I am here 18:09:18 Swami: thanks for joining 18:09:22 SumitNaiksatam: one thing on the test - we are on the fwd chain so we need to test vm on on net to vm on another 18:09:23 Just listening to what you complain about the DVR team. 18:09:30 not from the ns 18:09:34 Just kidding :) 18:09:38 Swami: :-) 18:09:38 i am doing some tests 18:10:02 Swami and others: so the update at this point is that we have the implementation working as defined in the spec 18:10:15 and also per discussions with the DVR team 18:10:26 SumitNaiksatam: Great work in a short span. 18:10:33 while doing some functional testing we are seeing some issues 18:10:44 and that is what we want to quickly firm up on 18:10:57 SumitNaiksatam: the ping test from namespace is probab not the right way to do it 18:10:58 Swami: all thanks to you and the DVR team (for the support and cooperation) 18:11:11 SumitNaiksatam: +1 on that 18:11:21 thanks swami 18:11:24 Swami: thanks so much for all the help 18:11:55 of course we need a big round of applause for SridarK for getting the implementation to where it is now (with surgical changes so as not disrupt too much) 18:12:22 Yes this is a required feature by both DVR and the community, it is good that you guys pulled it in. 18:12:23 SumitNaiksatam: no worries - if we make it that will be great - thanks 18:12:29 the patch is pretty small in terms of lines of code, so its a good thing (at least for the reviewers) 18:12:43 SridarK: Swami: back to you 18:13:08 Swami: we will need to close on that scenario when the router_add happens 18:13:28 That is clearly one issue that remains 18:13:31 SridarK: this is when a l3agent restarts. 18:13:39 Swami: yes 18:13:56 Yes we can discuss this on our 1.00p.m meeting with Mike 18:14:25 Swami: hopefully when we talk - i can quickly try out and confirm as well 18:14:26 I have already updated our folks with your requests. 18:14:31 Swami: thanks 18:15:09 SridarK: what about the snat use case? 18:15:16 Swami: on the ping test - from namespace - we probab should not do it that way - i am setting to do more tests on that area 18:15:30 SumitNaiksatam: - yes above is that case 18:15:40 SridarK: Yes that makes sense. 18:15:56 SumitNaiksatam: i have been breaking my head and went back to legacy and saw that issue as well 18:16:18 SridarK: ah ok 18:16:30 SumitNaiksatam: i then realized that since we are on the FORWARD chain we need to go from a VM on one net to another VM on another net 18:16:44 SumitNaiksatam: i wish i could have finished that to validate 18:17:04 SumitNaiksatam: yes brain function is now sub optimal :-) 18:17:12 SridarK: okay :-) 18:17:29 SridarK: so we need to apply in a different chain for the snat namespace? 18:17:43 SumitNaiksatam: no we are good 18:18:13 SumitNaiksatam: except we cannot source the traffic from the namespace - then it goes on the OUTPUT chain 18:18:20 SumitNaiksatam: we don't need to cover that 18:18:25 SridarK: ok 18:18:33 SumitNaiksatam: we just need to do the test differently 18:18:40 SridarK: ah ok 18:19:05 SumitNaiksatam: if i validate that on single node - we can quickly validate that on ur setup as well 18:19:07 SridarK: do the test in the reverse direction? 18:19:20 SumitNaiksatam: we have to have 2 nets 18:19:31 SumitNaiksatam: and 1 vm in each 18:19:47 and we have to do the traffic sourcing from one of the vms 18:19:48 SridarK: yeah 18:20:05 SumitNaiksatam: but let me test this on my single node setup 18:20:56 SumitNaiksatam: if that is good - we can do a quick run on the compute node use cases 18:20:57 SridarK: sure, may be after this meeting we can get together and test on my setup in parallel while you are testing your setup 18:21:02 In this case when you have two networks and try to ping between the vm's on network, how would you expect the traffic to go through the SNAT namespace. 18:21:05 Suqyes 18:21:17 Swami: yeah, i was not sure about that 18:21:25 Are you talking about external networks 18:21:36 since traffic between two VMs is E-W which we are not targeting there 18:21:40 there -> here 18:21:41 Swami: i am creating the networks on the network node 18:21:52 Swami: aah yes 18:21:57 If it is not external network, the traffic will still go through the East-West routers. 18:22:16 Swami: what we need is to forward thru the router 18:22:36 So we need to ping from a VM to an external entity 18:23:06 Yes, I think here it makes sense to ping from a VM to an external entity and not anything within the cloud. 18:23:08 Swami: SumitNaiksatam yes what i said would be how we would handle the legacy case 18:23:36 but on the DVR case - that will not work - it is more of a negative test 18:23:45 got it. 18:24:15 SridarK: so, there is only one outstanding issue? 18:24:20 Swami: SumitNaiksatam - i guess we should not test from the namespace - that will not hit the forward chain 18:24:40 SridarK: okay 18:24:41 SumitNaiksatam: yes i think if we can resolve the L3Agent restart case 18:24:43 Yes that makes sense. 18:24:50 SridarK: great 18:25:13 SumitNaiksatam: we were not able to ping external last nigh 18:25:21 SumitNaiksatam: more in terms of the setup 18:25:26 ok so for everyone else reviewing - i think we should separate out the “nice to have concerns” from what is a show-stopper in the review comments 18:26:14 i believe Sridark might post another patch 18:26:28 and can address some of the comments that are already there 18:26:55 other than that, please focus on critical issues with this patch 18:27:08 sridark: should we test it as a service node and compute node 18:27:15 the patch can be tested on your laptop by starting two VMs 18:27:35 badveli: yes the single node and multinode 18:27:41 badveli: thats what we are doing, and were hoping you would be doing to :-) 18:27:45 to -> too 18:27:54 yes this what i am trying 18:28:10 apart from the firewall rules 18:28:14 installation properly 18:28:24 we need to test the datapath 18:28:31 if you need the local.conf for the two VMs (network and compute node), please ping me 18:28:49 thanks sumit 18:28:54 badveli: yes, we have been testing the data patch 18:28:58 patch -> path 18:29:20 the compute node case is verified (when the FIP namespace is created) 18:29:24 ping to external world should be able to hit the rules in either single node or multi node 18:29:44 badveli: yes, thats the theory 18:30:19 thanks sumit, i will let you know 18:30:25 badveli: thanks 18:30:34 SumitNaiksatam: i think reaching something on the host was a problem for us correct 18:30:49 this is why we went into the namespace 18:31:14 SridarK: you mean for the compute node case? 18:31:40 SumitNaiksatam: for either case 18:32:25 SridarK: we will never be able to reach the host from the outside in the SNAT case 18:32:32 SumitNaiksatam: on the compute node we were able to see the rules taking effect when we pinged from the snat namespace 18:32:49 SumitNaiksatam: yes we need some way to test that 18:32:56 SridarK: the connection has to be initiated from the inside in that case 18:33:21 SridarK: for the compute node we did not test from the service node (that is not required) 18:33:30 SridarK: we tested from the compute node itself 18:33:49 SridarK: the ping from the outside (that is from my laptop) to the floating IP, did not work 18:33:55 SumitNaiksatam: yes we did it from the FIP ns 18:34:02 so we hit the fwd chain 18:34:08 SridarK: but that might be an artifact of the networking setup on my latop 18:34:28 SridarK: however we tested the ping from the FIP namespace and it worked 18:34:34 SumitNaiksatam: yes 18:34:47 Swami: any recos for testing the snat ns 18:35:01 I don't do it from my laptop. 18:35:11 The laptop setup is just for testing the control plane. 18:35:14 Swami: ok 18:35:29 But for snat setup I think we have a four node setup that we use in our testing. 18:36:07 Swami: u are tempting me to ask something :-) 18:36:26 Swami: but i will wait 18:36:27 If you have two nic in your laptop you should be able to do it from your laptop, but I have not played around it. 18:37:01 Swami: to ask the question a little differently 18:37:32 Swami: as badveli was pointing out earlier, would the SNAT case work exactly the same way regardless of one node or multi-node setup? 18:37:47 Swami: i am asking in the context of the firewall rule application 18:38:03 Swami: because if that is the case, I think badveli has a physical machine configured 18:38:08 SumitNaiksatam: Yes it would exactly the same way either single node or multinode, if it is configured for "dvr_snat". 18:38:17 Swami: sweet 18:38:43 Swami: and even in that case if we are to test on the laptop, you think we would need two nics? 18:39:08 Swami: i mean single node and “dvr_snat” 18:39:23 Just to test the traffic flow going outside of your VM to external network. 18:39:32 Swami: yes 18:39:55 Swami: you are saying we need more than one nic? 18:39:55 Otherwise to test the other options a single node should be sufficient enough. 18:40:15 good to hear 18:40:36 If you want to utilize the "br-ex" mapped to a physical network, then it would be great if you have two nics. 18:40:44 Swami: ok 18:40:53 One nic yu can use for management network and the other one for "external connectivity". 18:40:57 i have a physical machine with two nic 18:41:10 Swami: good point, and that is where actually having the two nics on the VM itself would have helped 18:41:26 Swami: remember i was telling you the issue with the devstack 18:41:46 Swami: if its a single nic, then br-ex takes over the management nic 18:42:31 anyway, let me not cause confusion here 18:42:46 Yes there is a way in devstack configuration to point your br-ex to use a specific interface. I have tried it long back, but I don't recall it right now. 18:43:07 Swami: yeah, i was not doing that, and hence the issue 18:43:10 anyway 18:43:28 SridarK: are you comfortable with the discussion here (pending the 1 PM webex call)? 18:43:39 SumitNaiksatam: yes 18:43:46 SridarK: nice 18:43:49 Swami: thanks 18:43:58 SumitNaiksatam: we just need to get the traffic out so we can hit the rules 18:44:12 SridarK: lets catch up on that immediately after this meeting 18:44:19 i will try with my phsical server 18:44:37 SumitNaiksatam: yes lets do that 18:44:39 badveli: thanks, yes we will need people to functionally test this 18:44:41 badveli: thanks 18:45:01 Swami: we might bug you :-P 18:45:06 thanks sridar, sumit, i will continue with a single node 18:45:13 no problem, do let me know 18:45:17 Thanks all for all the help 18:45:26 SumitNaiksatam: no problems 18:45:36 #topic Open Discussion 18:45:42 as far as I am not sleeping I will address your concerns. 18:46:01 also SumitNaiksatam many thanks - having a core help u with the testing is something awesome 18:46:02 Swami: great, thanks for making yourself available at odd hours 18:46:03 thanks swami 18:46:29 Swami: i hope u will not need to change ur cell num 18:46:34 :-) 18:46:35 * SumitNaiksatam notes that Swami sleeps very late (going by yesterday’s conversation close to midnight), but does not want to stretch his luck too far! ;-P 18:46:46 SridarK: You called my home phone last night 18:46:46 SumitNaiksatam: +1 18:46:47 SridarK: :-) 18:47:00 SridarK: Use my cellphone if it is at night. 18:47:09 anything else we need to discuss? 18:47:15 Swami: oh good god - sorry - i think i redialed from ur call without thinking - so sorry 18:47:28 gduan: natarajk: anything at your end? 18:47:31 the meeting at 1:00 is it at irc 18:47:43 badveli: SridarK will setup webex 18:47:47 badveli: i will post u the location 18:47:53 we might need to share screens 18:47:53 thanks sridar 18:49:01 bye guys. 18:49:13 Swami: thanks bye 18:49:54 alright lets wrap up, and back to the trenches! 18:49:59 thanks all for attending 18:50:02 ok thanks 18:50:03 #endmeeting