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