18:02:12 #startmeeting Networking FWaaS 18:02:13 Meeting started Wed Jan 8 18:02:12 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:16 The meeting name has been set to 'networking_fwaas' 18:03:36 #topic FWaaS tempest tests 18:03:43 #link https://review.openstack.org/#/c/64362/ 18:04:05 this is the initial cut for the API tests 18:04:30 fried around? 18:04:36 I will take a look at the review 18:04:40 *yfried 18:04:48 RajeshMohan: thanks 18:05:22 RajeshMohan: the first step is that we need to request enabling of q-fwaas on the gate 18:05:55 ok 18:06:04 for that we need to ensure that enabling q-fwaas does not disrupt running the existing tests 18:06:15 Is anyone else working on tempest? 18:07:15 RajeshMohan: to some extent many people are looking at it 18:07:19 including me 18:07:24 SridarK around? 18:07:56 I ran devstack with q-fwaas and q-vpn and at least the installation went through peacefully 18:08:12 but we need to do more thorough testing 18:08:16 #link http://lists.openstack.org/pipermail/openstack-infra/2013-December/000579.html 18:09:26 clarkb in this thread mentioned that there was an issue that they saw earlier when they turned on q-fwaas 18:09:42 but i am not sure what exactly that issue was 18:09:47 clarkb: there? 18:11:19 I do not see clarkb on that thread 18:11:22 perhaps not 18:11:39 I see Salvatore, yourself and Yair 18:12:22 #link http://lists.openstack.org/pipermail/openstack-infra/2013-December/000586.html 18:12:39 RajeshMohan: see ^^^ this message, it's embedded inside 18:14:04 ok 18:14:14 he might have replied privately 18:14:20 did not realize that 18:14:24 anyway 18:14:40 i think we need to do our due diligence before recommending 18:15:31 so, the goal is to make sure vpnaas and fwaas can work togehter? 18:15:47 RajeshMohan: yeah 18:16:17 RajeshMohan: before that we need to make sure that install goes smoothly (i kind of verified that) 18:16:36 Makes sense 18:16:43 RajeshMohan: then we need to run the existing tempest suite, and make sure that it passes (with q-fwaas turned on) 18:16:59 this will not have q-fwaas tests yet, but at least that should pass 18:17:10 ok 18:17:18 then we will be in a position to recommend that we are not disruptive 18:17:37 once that is turned on, the patches such as above can be reviewed 18:17:58 currently even if the patch is reviewed, it can't be merged 18:18:38 ok 18:19:13 ok if nothing else immediately on tempest, then let's move forward 18:19:43 #topic Service context and Insertion 18:19:56 #link https://review.openstack.org/#/c/62599/6 18:20:00 RajeshMohan: your patch 18:20:13 Yes - UT is still pending 18:20:13 RajeshMohan: we had lots of discussions over emails 18:20:18 RajeshMohan: np 18:20:33 RajeshMohan: i did not get a chance to look at the latest 18:20:53 Yes - please look at it and send me your comments 18:21:08 RajeshMohan: we are planning to make the agent and driver side changes as well, right? 18:21:11 I am also working on migration scripts - will update the patch today 18:21:23 Yes - that's the plan 18:21:25 RajeshMohan: great 18:21:40 Changes should be on agent only 18:21:51 Driver changes may not be needed 18:22:50 Maybe in update path (when routers are removed in service context), there may be changes in driver code 18:23:25 I have to think through that - CREATE and DELETE will be simple changes 18:23:48 RajeshMohan: okay, yeah i thought changes to the driver should be minimal 18:25:22 RajeshMohan: anything currently blocking you (apart from more reviews)? 18:25:36 No, I am good. 18:25:42 RajeshMohan: ok great 18:26:18 RajeshMohan: when the patch is closer to being ready, we need to engage other cores 18:26:27 RajeshMohan: start with nati_ueno 18:27:03 i will reach out to him as well 18:27:07 Ok, I will ping Nachi 18:27:17 Ok. Thanks. 18:27:33 RajeshMohan: anything more on this topic? 18:27:55 For exisiting unit test cases - i had a question 18:28:03 ? 18:28:07 is it ok to change existing test cases? 18:28:29 I have managed to make all the test cases work without changes except 2 18:28:43 Both in fwaas-extention test case 18:29:30 The Firewall object return "service_cntext: None" 18:29:48 When service context is not configured 18:31:25 okay 18:31:30 that does not work? 18:32:06 The expected result does not have "service_context" 18:32:28 Let me spend some more time on it 18:32:54 Maybe there is something I can do with the Mock to not set it when it is None. 18:33:20 The actual Firewall GET will not return service_context if it is not configured 18:33:36 hmmm 18:33:42 That's how all the other existing test cases work without change 18:33:43 i am not sure if that's the right approach 18:34:12 ok - what do you suggest? 18:34:43 shouldn't we be sending back empty service_context? 18:35:28 come to think of it, i guess the service_context should never be empty, right? 18:35:47 its optional for the user to specific 18:35:51 I started with that - but for backward compatibilty - I decided to go down this path 18:36:06 but we will have a default context if none is specified during resource instance creation 18:36:39 ah okay, but i think we don't need to worry as much about backward compatibility at least for fwaas 18:36:47 So, GET should show empty or all the routers? 18:38:42 If we show routers, then we may need a way to say that it is default and not what was configured 18:39:10 i am thinking GET should give back {'service_context': {'routers': [], 'subnets': [], 'ports': [], 'networks': []} 18:39:26 i am not sure that we need to indicate that its default or not 18:40:01 So, the router_id will be list of all routers (in case of default) 18:40:09 we will not use default if the user configures the router_id, right? 18:40:48 ah good, question, so you are asking if the default applies means apply on all routers 18:41:01 i guess that should be the case, we are doing that now as default 18:41:13 Other option is to return {'service_context': {'routers': [], 'subnets': [], 'ports': [], 'networks': []} 18:41:36 But this means that the firewall rules are applied on all routers 18:42:22 if we return empty, that means its not applied on any routers 18:42:38 i would not interpret that as being applied on all 18:42:48 so, we do {'service_context': {'routers': [], 'subnets': [], 'ports': [], 'networks': []} 18:43:02 i would think so 18:43:05 when no service_context is configured 18:43:12 ok 18:43:23 in the case of the fwaas implementation with perimeter firewalls 18:43:53 BTW - as a side effect, most exisitng unit test cases will change 18:44:25 that should be fine 18:44:45 i was going to say that the defaults might be different for a different provider and/or a different service 18:45:30 right 18:45:45 okay, not stating anything new, just what we had discussed 18:46:16 gduan: around? 18:46:19 In this BP, we only worry about L3 reference implementation 18:46:30 RajeshMohan: yeah, sure 18:46:42 thats why i was checking for gary duan 18:47:03 because we currently have not tied in the service provider for fwaas, his patch is doing that 18:47:42 so to your point, that is the default implementation with the default provider (once the provider notion gets added as well) 18:48:19 anyway since gary is not around we can skip the discussion on #link https://review.openstack.org/#/c/60699/ 18:48:31 on the same point provider patch - the second patch that does in will have more change 18:48:34 and lets follow up with him 18:48:56 RajeshMohan: ? did not get that 18:49:08 if service-insertion patch goes in after provider patch, then I may have more changes 18:49:17 RajeshMohan: ah ok 18:49:30 RajeshMohan: agree, this will potentially be complicated 18:49:46 RajeshMohan: i mean complicated for gary to merge if he goes second 18:50:11 RajeshMohan: are you fine with us pushing for provider patch merging in first? 18:50:25 How close is Gary's patch to merge? 18:50:44 He started first - so I am ok with merging mine with his changes 18:50:57 seems like he added UTs 18:51:03 but is MIA for a while 18:51:16 I see 18:51:19 lets try to track him 18:51:28 Must be the holidays 18:51:42 yeah, also he was not keeping well 18:51:52 I see 18:51:56 i think his patch is more straightforward 18:52:28 since it goes along the precedence of lbaas and vpnaas 18:52:30 Ok, I will start planning into merging with his 18:52:37 RajeshMohan: great thanks 18:52:52 anything more on this topic? 18:53:06 since gary and yi are not here we can discuss more on this if required 18:53:30 otherwise i don't have anything more for today'a agenda 18:54:20 We have plan on Horizon changes for service-insertion 18:54:42 RajeshMohan: oh good point 18:54:44 I meant 'we have to plan on ...' 18:54:54 yeah we don't have an owner for that right now 18:55:22 right 18:55:52 it is not required for the default case, but if the user has to provide input, then its required 18:56:12 That's true. It will continue to work 18:56:50 RajeshMohan: you have some experience with horizon as well, right? 18:57:06 Yes - little bit 18:57:12 mostly cut & paste 18:57:31 I can do it if time permits 18:57:36 RajeshMohan: ok we can explore how we can do that patch, the two of us can discuss 18:57:50 ok 18:57:51 RajeshMohan: if you can drop some knowledge on me, i can give it a shot :-) 18:58:20 you definetely know more than me :-) 18:58:38 #action RajeshMohan SumitNaiksatam find owner for service insertion context for fwaas 18:58:39 I learnt mostly by looking into Fwaas Horizon changes 18:59:28 #topic Open Discussion 18:59:37 we have < one min 18:59:47 regarding next week's meeting, we will have if required 18:59:59 makes sense 19:00:00 we might go to a bi weekly format soon 19:00:05 sorry i was late - should calendar the mtg 19:00:09 will send out an email to that effect 19:00:13 SridarK: np 19:00:21 SridarK: lets catch up later 19:00:27 thanks all for joining! 19:00:30 sounds good will ping u after 19:00:37 #endmeeting