18:40:15 #startmeeting Networking FWaaS 18:40:16 Meeting started Wed Aug 13 18:40:15 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:40:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:40:18 hemanth_: well, we can talk to the lbaas folks at 2pm if you are available 18:40:20 The meeting name has been set to 'networking_fwaas' 18:40:38 #topic Action item review 18:40:45 s3wong, will join that 18:40:54 hemanth_: great, ttyl 18:41:18 i think webex meeting with DVR team is done, SridarK thanks for following up 18:41:29 yes SumitNaiksatam - good mtg 18:41:51 is the wiki page for FWaaS support for DVR up? 18:41:51 we can cover discussion on that topic 18:41:56 Sumit swami mentioned about the migration path 18:42:05 sridar and myself are looking at 18:42:18 SumitNaiksatam: no sorry not yet too many balls in the air - we will get this done soon 18:42:24 SridarK: ok 18:42:26 also we get info on simulating evrryting in a single node 18:42:31 badveli: hang on 18:42:57 #action SridarK badveli to populate wiki page for FWaaS DVR support 18:43:13 sumit: we will do 18:43:50 badveli: thanks 18:44:09 we also had action item for posting patch, SridarK did that, thanks! 18:44:22 SumitNaiksatam: yes done np 18:45:00 SridarK: can you update https://wiki.openstack.org/wiki/Neutron/FWaaS/JunoPlan 18:45:09 with link to patch? 18:45:17 SumitNaiksatam: will do so right away 18:45:23 Sumit: we will refine it based on our discussion with dvr team 18:45:35 SridarK: thanks, i was trying to past the link to the patch here :-) 18:46:31 hi 18:46:34 #link https://review.openstack.org/113359 18:46:35 #link https://review.openstack.org/#/c/113359/ 18:46:38 Swami: hi 18:46:43 SumitNaiksatam: :-) 18:46:47 ok i think we are done with the action item review 18:47:15 since Swami is here, lets jump to the DVR topic, and then we can circle back to the bugs 18:47:31 #topic FWaaS support for DVR 18:47:40 #link https://review.openstack.org/113359 18:47:58 SridarK: you want to summarize from yesterday’s meeting with DVR team? 18:48:19 SumitNaiksatam: sure 18:48:32 we discussed overall approach 18:48:54 step1: get the network node done - currently in first patch 18:49:18 comments to change the demux based on the distributed flag in router info 18:49:38 SridarK: this is for the SNAT traffic? 18:49:50 step 2 on Compute node changes to make sure we do not break E - W traffic 18:50:02 SumitNaiksatam: yes N - S traffic thru the snat NS 18:50:17 SridarK: which step covers the floating IP? 18:50:38 SumitNaiksatam: we are targeting fixed ip now as in our current model 18:51:01 once we have that figured we can see if we can attack floating ip as well 18:51:45 SridarK: ok 18:51:47 SumitNaiksatam: The North-South has two parts, one for the VM traffic that goes through the SNAT namespace and the other FIPs assigned VM traffic that goes through the FIP namespace. 18:52:02 Swami: ok thanks 18:52:09 So I think SridharK is working on the first item right now. 18:52:19 Swami: but the FIP translation happens on the compute node, right? 18:52:23 Swami: yes 18:52:38 SumitNaiksatam: Yes in the IR of the compute node. 18:52:54 SumitNaiksatam: Swami that we target in the step 2 18:53:02 Swami: SridarK so we will attempt that as step 2 or 3? 18:53:07 SridarK: yeah my question 18:53:26 i think we will get fixed ip working first 18:54:01 SumitNaiksatam: i think we can apply rules in a way so we either get post or pre NAT 18:54:54 one suggestion was to bind that to the rfp- i/f which is the path to the FIP NS 18:56:21 Our immediate action is to use Swami 's suggestion of getting a single node install (which simulates the compute node as well) - to play with the IR and FIP NS interactions 18:56:42 once we have a handle on that we can make a call on the Floating IP 18:56:47 SridarK: that sounds good 18:57:16 over all good mtg and thanks to the DVR folks for being really supportive and helpful 18:57:16 Swami: SridarK badveli are we on the same page on this? 18:57:41 yes 18:58:04 l also wanted to check with armax since he was included on the thread by mestery 18:58:17 SumitNaiksatam: We are on the same page. 18:58:27 Swami: thanks for the help 18:58:35 SumitNaiksatam: +1 on that 18:59:19 SumitNaiksatam: sorry folks I wasn’t paying attention 18:59:23 armax: please let us know if you are in agreement with the approach that is being taken here 18:59:26 SumitNaiksatam: what can I do for you? 18:59:27 armax: yeah sure 18:59:32 armax: :-) 18:59:41 armax: just wanted to make sure you are in the loop as well 18:59:55 armax: mestery included you on the thread regarding the FWaaS support for DVR 19:00:08 SumitNaiksatam: oh right 19:00:09 and the FWaaS team has been in discussion with the DVR team on this 19:00:18 we had a call yesterday 19:00:27 SumitNaiksatam: I am on the review https://review.openstack.org/#/c/113359/ 19:00:30 to sync up on the progress so far and the path forward 19:00:44 armax: yes, great 19:00:46 SumitNaiksatam: is it good to review/play with 19:00:46 ? 19:00:56 SridarK: ^^^ 19:01:00 armax: not yet still WIP 19:01:03 armax: i believe not right away 19:01:07 SumitNaiksatam: we’re definitely looking at fwaas 19:01:21 SumitNaiksatam: in the dvr case there are tempest failures that I haven’t looked at 19:01:35 SumitNaiksatam: but I was hoping that SridarK’s changes might help address them 19:01:44 armax: we had a mtg set up earlier - pls let me know in case i should include u in any offline calls that we may have 19:02:09 SridarK, SumitNaiksatam: posting ‘check experimental’ on the above mentioned patch should give you a clue on the effects of your patch on DVR 19:02:19 SridarK: that should get some pressure off from manual testing 19:02:44 SridarK: feel free to keep me in the loop, I cannot guarantee I’ll be able to respond promptly…I am drowning over here :) 19:02:45 armax: u were really quick to add that thanks even b4 i could mark it WIP :-) 19:02:54 armax: understood will do 19:03:05 SridarK: momentary lapse of a reason ;) 19:03:30 armax: u give away ur age referring to some Pink Floyd y stuff :-) 19:03:41 SridarK: are you saying that I am old? 19:03:41 :) 19:03:47 :-) 19:04:00 I guess you must be too ;) 19:04:15 armax: my hairline gives that away 19:04:34 SumitNaiksatam: sorry back to mtg 19:04:36 ok great, lets move on wise old men! :-P 19:04:42 SridarK: don’t even get me started on hairline, I am not coping well with my hair loss, but yes back to business 19:05:05 badveli: how is the set up coming along? 19:05:22 i am trying to follow sami suggestions 19:05:29 sorry swami suggestions 19:05:36 badveli: ok 19:05:40 simulating in a single node 19:05:46 badveli: sorry i cut you off earlier 19:05:55 no problem 19:06:03 badveli: if you dont mind, can you please provide that update again? 19:06:19 there is another thing that swami had braught up yesterday 19:06:31 the migration 19:06:37 badveli: ok 19:07:15 if user converts a router to dvr on the fly 19:07:21 so migration of an existing fwaas installation to one with DVR? 19:07:26 yes 19:07:31 badveli: ok 19:07:43 we need some mechanism to listen to 19:07:51 currently we listen only to router add 19:08:05 badveli: listen to what? 19:08:22 we do not act on the router updates 19:08:30 we do not have a way to know it 19:08:39 badveli: yes 19:08:54 however, we have not explicitly stated that we will support migration in our spec 19:08:56 we need a mechanism first to know about this 19:09:19 SumitNaiksatam: Yes you have not stated in your spec. 19:09:39 The dvr team has a backlog item that we are working on for the router migration. 19:09:41 what is the implication now 19:09:45 Swami: ok 19:09:58 Swami: is taht something that is being targeted for J3? 19:09:59 I was wondering if you have any communication mechanism that can be utilized to clean up the rules during the migration. 19:10:14 Yes the migration patch is currently targeted for Juno 3 19:10:17 SumitNaiksatam: but if the dvr team needs a clean way for migration - and if fwaas is installed - we need to have consistent way of handling this 19:10:42 Swami: with an rpc for that - we can handle that 19:10:47 Swami: the agent listens to the rpc channel 19:11:51 SridarK: yes, like you said 19:11:53 SumitNaiksatam: Yes I agree that the rpc channel would be right approach. My question is who owns that rpc? I= 19:12:25 Swami: i think SridarK and badveli indicating that we need to listen to the migrate event 19:12:39 Swami: can it be a plugin to L3Agent RPC that we can add hooks into 19:12:44 SumitNaiksatam: yes 19:12:49 Today migrate is a regular "update". 19:13:09 Swami: ok, so the concern is taht fwaas would need to listen to all updates? 19:13:11 So if you can add a hook into the "router_update" rpc then it should work. 19:13:18 Swami: yeah 19:13:39 we are already in the same footprint of the l3 agent 19:14:01 let me check that code 19:14:06 Right now we have a state flag defined for router update as "migration". 19:14:17 Swami: that should work 19:14:18 Swami: do you have the information published somewhere? 19:14:30 But we need to decide if we are going to send it to the agent as such or modify it before sending it to the agent. 19:14:33 Swami: ah just asking that 19:14:43 We have a current patch for it upstream. 19:15:22 #link https://review.openstack.org/#/c/105855/ 19:15:31 thanks swami 19:15:42 There are couple of router states that we have defined in the "neutron/common/constants.py" 19:16:48 For now think about this idea and let me know. 19:17:21 we will go through it 19:17:24 SridarK badveli: can we document our approach in the wiki? 19:17:34 SumitNaiksatam: sure 19:17:36 yes 19:17:39 once we decide what to do, and perhaps get it reviewed 19:17:45 by the DVR team 19:18:07 fine sumit, we will think about this based on the new info by swami 19:19:02 sumit:should we traget juno3 19:19:08 ? 19:19:16 badveli: you mean for the migration? 19:19:21 yes sumit 19:20:30 if we allow the migration, we will not be correct 19:20:54 badveli: i think we should target J3 19:21:18 but my understanding is that we have a dependency on the DVR team 19:21:51 Swami: what is VPNaaS doing about this? 19:22:35 SumitNaiksatam: nice question, the current proposal for VPNaaS is to check during update, if the router has an associated VPN service. If so , we will raise an exception and say DVR does not support VPNaaS 19:23:00 We are also planning to add a check in the VPNaaS service before associating a DVR router. 19:23:37 Swami: should we do the same with FWaaS? 19:24:03 Is there a valid check for FWaaS with respect to a router. 19:24:19 SumitNaiksatam: this was the issue for us 19:24:20 Swami: not with respect to a particular router 19:24:22 If we have a valid check we can do the same way. 19:24:42 That was my concern and that is the reason I brought it up to you folks. 19:24:42 Swami: the check will be if FWaaS is present for this tenant 19:24:52 Swami: sorry 19:25:06 Swami: i meant if a firewall is present for this router 19:25:43 Yes we can do that simple check. 19:26:07 Swami: since the firewall is applied on all routers 19:26:17 And probably advice the admin to remove the FWaaS affinity towards the router and then migrate the router. 19:26:17 yes 19:26:23 Swami: badveli do you see an issue with that? 19:26:36 Swami: it wont be just for that router 19:26:41 Swami: is there a case where u can have different router types in a single tenant 19:26:44 Swami: the admin will have to remove the firewall 19:26:45 sumit: I think it should be fine 19:27:19 It is not tenant driven it is admin driven 19:27:34 Swami: and if we do a migration for a specific router that is in legacy to distr 19:27:36 So an admin for force a router to be "legacy" or "distributed" and can have a mix. 19:27:38 Swami: the firewall is owned by the tenant 19:28:23 Swami: let me back track a little 19:28:30 So if firewall is configured for that tenant, an admin should not move the router, until the tenant removes the FWaaS, that is one way 19:28:32 Swami: SumitNaiksatam that mixed condition probab needs mor thought 19:28:47 Swami: you said - the current proposal for VPNaaS is to check during update, if the router has an associated VPN service. If so , we will raise an exception and say DVR does not support VPNaaS 19:29:26 SumitNaiksatam: yes you are right. The reason is we don't have a VPNaaS solution for DVR yet. 19:29:26 Swami: did you mean to say - we will raise an exception and say *migraton to DVR* is not supported for VPNaaS? 19:29:41 Swami: ah ok, so VPNaaS itself is not supported 19:29:59 Our expection message will state the router is in use by VPNaaS. 19:30:07 Swami: ok 19:30:24 Swami: similarly can you raise the exception that the router is in use by FWaaS? 19:30:54 Swami: the tenant which owns the firewall (it may or may not be admin) can then remove the firewall in response to this exception 19:31:02 sumit, i think we need to think more on this, as swami pointed out 19:31:09 Yes it can be done, the only issue I had was there was no direct corrilation between a router and a firewall. 19:31:09 SridarK: am i missing something? what is the mixed case? 19:31:18 Swami: there is 19:31:33 SumitNaiksatam: when we have some dist routers and some legacy routers in a tenant 19:31:37 router:firewam is n:1 19:31:50 If there is a direct correlation between a FWaaS and router, we can make use of it and raise an exception. 19:31:50 sumit: even if we throw exception and ask to remove the firewall 19:31:51 and if FWaaS is configured after 19:32:04 SumitNaiksatam: and then we trigger migration 19:32:11 if remove the firewall and then configure dvr 19:32:21 SumitNaiksatam: i am not sure if this is a valid use case 19:32:31 SridarK: the same logic will apply, right? 19:32:37 and then if firewall is configured 19:32:42 SumitNaiksatam: i was just saying we should go thru the use cases to be sure we don't miss 19:32:53 SridarK: because we are still left with only one firewall per tenant 19:32:58 Something is better than not breaking anything while we migrate. 19:33:00 SridarK: in the absence of service insertion 19:33:04 do we need to handle the reverse case? 19:33:10 SumitNaiksatam: but the tenant has different types of routers 19:33:20 SumitNaiksatam: i am not sure that there is an issue 19:33:32 SridarK: ok, but its still one firewall, right? 19:33:34 SumitNaiksatam: just more investigation to make sure 19:33:39 SumitNaiksatam: yes 19:33:41 SridarK: i am not sure that is an issue with migration 19:33:54 SumitNaiksatam: for vpnaas - it is also one specific router that they track 19:33:57 swami: as you had mentioned the reverse case 19:34:00 SridarK: SumitNaiksatam:badveli: Please give it a thought and we can discuss this through email exchange what would be the right option. 19:34:07 SumitNaiksatam: where we are different 19:34:10 SridarK: its an issue about supporting both modes at the same time 19:34:17 Swami: quick question on VPNaaS + DVR, will we raise a similar exception if the router is in dvr mode and tenant tries to create a vpn connection ? 19:34:19 SumitNaiksatam: yes 19:34:33 SumitNaiksatam: and if that is even valid 19:34:53 ok we are running short of time 19:34:55 Yes we are planning to prevent it from happening. I have raised a bug for it. 19:35:02 so a suggestion 19:35:11 swami> the reverse case is a valid one? 19:35:21 from dvr to legacy 19:35:44 we allowed to go to dvr 19:35:53 #link https://bugs.launchpad.net/bugs/1356467 19:35:54 Swami: the router on a single node is considered as a legacy or still a DVR? 19:35:56 and then user configured firewall 19:36:33 SumitNaiksatam: The router on a single node will still be considered 'dvr' if the agent is running in a dvr mode. 19:36:43 Swami: ok good 19:36:44 Swami: thanks! 19:36:49 so my suggestion 19:36:54 sumit: my worry is we need to consider the check in both directions 19:37:21 how about we only support either the legacy router, or the DVR 19:37:24 at any given time 19:37:29 not a combination 19:38:02 SumitNaiksatam: ok so it is a tenant wide attribute for the router type 19:38:04 also migration for legacy router to DVR will not be supported, if firewall is associated with tenant 19:38:22 SridarK: only when using FWaaS 19:38:41 SumitNaiksatam: yes interesting thought 19:39:18 i am proposing that we constrain the scenarios we support 19:39:30 SumitNaiksatam: and we can probab check that as new routers are added 19:39:37 SridarK: yeah 19:40:04 sumit: should we consider the same from moving dvr to legacy 19:40:40 badveli: Right now converting a dvr to centralized router is not targeted and is of low importance. 19:40:43 badveli: yes 19:40:51 Swami: yeah 19:40:57 so to summarize 19:41:32 1. An exception is raised when attempting to migrate a legacy router to DVR if a FWaaS firewall is associated with it 19:41:59 the remediation would be to delete the firewall for that tenant 19:42:05 and then attempt the migration again 19:42:53 2. FWaaS firewall can be applied only when all the routers for a tenant are of the same type (either DVR or legacy) 19:42:57 +1 on option 1 19:43:45 3. An exception is raised when attempting to migrate DVR to legacy router if a FWaaS firewall is associated with the DVR 19:43:53 SumitNaiksatam: (2) can be done quite easily 19:44:01 SridarK: thats nice 19:44:15 Swami: badveli: your opinion on 2 and 3? 19:45:07 i think 2 is a good 19:45:08 SumitNaiksatam: i think u have covered all cases 19:45:27 looks to me but as swami pointed out the reverse one is not a important one 19:45:33 3 is also good 19:45:35 Swami: ? 19:45:36 Do you guys want to check each and every router before a FWaaS is assigned to make sure if they are all of the same type. 19:45:53 badveli: i can point u to code for (2) if u want to dig more on this 19:46:05 thanks Sridark 19:46:10 I will sync up with you 19:46:20 Swami: we already have to apply the firewall on all routers 19:46:23 badveli: sounds good 19:46:46 Swami: and these are routers per tenant 19:46:57 Swami: not the global space 19:47:00 Yes, but as routers are created, how will you keep track of all routers. 19:47:18 Swami: we plug into router creation 19:47:30 In terms of tenant's routers they are always going to be the same. 19:47:41 as that is when we add FWaaS rules to new routers as they are created 19:47:42 Unless an admin modifys the tenant's router. 19:48:35 So summit are you guys planning to do all three options: 1, 2 and 3. 19:49:13 Swami: i am asking 19:49:50 Swami: so 1 and 3 are complementary 19:49:50 Option 2: The tenants will always get the same type of routers and they don't get a choice to change the mode. 19:50:06 So your existing code should work on Option 2. 19:50:24 Swami: sorrry i did not understand 19:50:38 Swami: i thought you said you are supporting a mixed mode 19:50:44 Option 1: and Option 3: are for both direction migration 19:51:02 Swami: wherein a given tenant could have both DVR and legacy routers at the same time 19:51:07 Swami: is that not the case? 19:51:34 SumitNaiksatam: I mentioned that we support mixed mode even on a single node. But only for "admin". A tenant may only create a single type of router that is been defined by the "cloud admin". 19:52:22 Swami: ok 19:52:44 Swami: so then the option 2 still applies, since there is at least some way to have routers in a mixed mode 19:52:59 Yes I agree. 19:53:58 Swami: and in that case i am saying, that if one wants to apply FWaaS firewall, then the mixed mode will not be supported 19:54:18 Swami: so in other words, lets say we have a DVR 19:54:32 Swami: and a FWaaS firewall applied to that 19:55:04 Swami: and then the admin tries to create a legacy router 19:55:25 Swami: we can check for that tenant, and disallow the legacy router creation 19:56:11 Swami: similarly, if a DVR and legacy router exists, and now the FWaaS firewall is attempted to be created for that tenant 19:56:19 Swami: we will not allow the firewall creation 19:56:32 You mean you will prevent the migration based on the tenant and the firewall 19:57:00 Swami: migration is cases 1 and 3 19:57:08 Swami: we are talking about case 2 19:57:50 In case when you say you are going to disallow the legacy router creation. Will the firewall block the router creation. 19:57:55 Swami: not migration, either bein able to create routers in the mixed mode (when FwaaS firewall is present) or being able to create Fwaas firewall when routers in mixed mode are present 19:58:31 Swami: that is something we need to decide 19:58:40 SumitNaiksatam: I think we need some phone line discussion for this topic. I am missing something. 19:58:45 SumitNaiksatam: FWaaS creation failure on a tenant with DVR and legacy - can be done for sure 19:58:51 Swami: i think the check is similar to the check for migration 19:59:28 SumitNaiksatam: but as u suggest the first case in (2) depends on DVR as we usually pick up the router creation event 20:00:12 SridarK: can we perform all the checks in the firewall code? 20:00:24 Yes, DVR should basically allow router creation either way based on the "global default" flag or the admin overriden flag. 20:00:27 SridarK: as opposed to DVR having to throw any of these exceptions? 20:00:40 We can perform the checks for both cases in 2 20:00:58 we can act on 2b - fail fw creation 20:01:10 if we have the router update events 20:01:12 SridarK Swami: so essentially all three cases are covered by router create and update events 20:01:24 but on 2a - preventing a router of specific type from getting created - that is a bit tricky 20:01:34 badveli: yes we dont act on them yet (if i recall correctly) 20:02:10 SridarK: dont we just have to check if any existing router is of a different type? 20:02:23 SumitNaiksatam: yes we can do that for sure 20:02:27 SridarK: as soon as we encounter the first one, we raise an exception 20:02:36 SridarK: if not we continue checking 20:02:39 SumitNaiksatam: aah ok we just raise the exception 20:02:51 Sumit: We can start thinking about the three cases 20:02:54 SridarK: of course the first check is that a firewall is present for this tenant 20:03:00 in firewall 20:03:05 SumitNaiksatam: we cannot control the router creation of a diff type 20:03:18 SridarK: why? 20:03:41 SumitNaiksatam: once we get the router added - the router is already there 20:03:48 SridarK: ah becuase, we inherit from the l3 agent 20:03:56 SumitNaiksatam: yes 20:04:02 so i take back all that i said then 20:04:07 SumitNaiksatam: so we can say that this is a problem 20:04:23 SumitNaiksatam: but we cannot stop the router creation as it is already there 20:04:26 Swami: then those exceptions have to come from DVR 20:04:38 Swami: so we can stop the firewall creation 20:04:42 Swami: not the router creation 20:05:18 SumitNaiksatam: where do you want the firewall creation to be stopped. 20:05:27 SumitNaiksatam: trying to create a fw on a tenant with diff router types - we can handle for sure 20:05:33 Swami: we can control the firewall creation in the firewall code 20:05:39 Swami: you need not have to worry about that 20:05:54 Swami: as SridarK said 20:06:03 Swami: its the router creation that you would need to control 20:06:35 Swami SridarK even for that, can we define some kind of a pre-commit hook in the DVR? 20:06:44 that fwaas can implement 20:06:55 so prior to router creation, DVR can just call that hook 20:07:06 if fwaas is configured 20:07:12 guys I think we are complicating things here. 20:07:26 then the fwaas can decide whether to throw an exception 20:07:34 The minimum requirement here is option 1: for migration. 20:07:42 that way none of the fwaas specific logic leaks into the DVR 20:08:27 Swami: even for that option, rather than the DVR code doing a check for firewall, it can just make a call on the fwaas hook 20:09:24 Yes, that would be nice. 20:10:02 Swami: that way you dont even have to do the processing for raising the exception 20:11:06 ok we are way over the meeting time 20:11:21 SumitNaiksatam: we have set a record :-) 20:11:23 SridarK badveli: do you want to summarize this and add ot the wiki? 20:11:33 we will discuss and will do 20:11:40 and perhaps Swami and the rest of the DVR team can review it once there 20:11:45 thanks for the inputs swami and sumit 20:11:45 SumitNaiksatam: sure - we can may be also have an email thread 20:11:52 sridar and myslef will sync up 20:11:59 and write down 20:12:11 thanks guys 20:12:13 bye 20:12:18 bye 20:12:18 #action SridarK badveli to update FWaaS/DVR wiki and add migration and mixed mode operation semantics in presence of fwaas firewall 20:12:29 thanks all for attending 20:12:32 #endmeeting