18:03:15 #startmeeting Networking FWaaS 18:03:16 Meeting started Wed Mar 5 18:03: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:03:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:19 The meeting name has been set to 'networking_fwaas' 18:03:37 we will keep the agenda short for today 18:04:14 lets focus on Rajesh's patch 18:04:27 everyone agree? 18:04:32 yes 18:04:41 ok 18:04:47 ok 18:04:52 RajeshMohan: thanks for being at this 18:05:00 +1 18:05:07 RajeshMohan: i am sure you haven't slept! 18:05:22 RajeshMohan: for the past couple of days that is 18:05:35 RajeshMohan: what is the latest, i saw the new UT is failing 18:07:30 RajeshMohan: there (i know he is), just redirecting him to the right channel :-) 18:07:55 sorry about that 18:08:18 the last change I made was to check for router-in-use 18:08:33 that test-case - when called from db-test works 18:08:42 yes exactly 18:08:42 plugin inherits all db-test 18:08:48 i tried that too 18:08:55 but it fails when called from plugin 18:09:03 and when u run the fwaaplugin it fails 18:09:07 I think I have to set no-delete = True 18:09:40 becuase the firewall delete when called from plugin does not call real delete 18:09:42 RajeshMohan: ok 18:09:43 hi 18:09:51 nati_ueno: hi 18:09:56 nati_ueno: hi 18:09:59 nati_ueno: thanks for joining 18:10:09 SumitNaiksatam: :) 18:10:16 nati_ueno: we are just discussing that one test case 18:10:35 router delete in use? 18:10:40 nati_ueno: yes 18:11:17 ah sorry, jenkins is failing for this.. 18:11:18 RajeshMohan was having problems getting to work when called from the plugin 18:11:28 RajeshMohan: go ahead 18:11:31 May be, I'm still sleeping.. 18:11:33 nati_ueno: when the new test case gets called from fwaas-plugin, the firewall-delete is not called 18:11:49 nati_ueno: there is an option called no_delete=True 18:12:15 nati_ueno: I suspect I have to set that to True and then the actual Firewall delete must get called 18:12:40 nati_ueno: the same test case workswhen called as part of DB test cases 18:12:42 no_delete option is for deletion test 18:12:54 I thought, if we set it True, it won't be deleted.. 18:13:02 nati_ueno: that's right 18:13:31 so may be, we need to fix the fwaas base test cases.. 18:13:33 let me see.. 18:13:35 nati_ueno: currently, the actual delete_firewall is not called 18:14:03 RajeshMohan: so agent will update the status when the resource deleted. 18:14:08 so IMO, we should mock it 18:15:08 nati_ueno: ok - will try that option 18:15:35 https://github.com/openstack/neutron/blob/master/neutron/tests/unit/db/firewall/test_db_firewall.py#L168 18:15:43 It looks like no status update code here 18:16:16 ah sorry wrong link 18:16:16 https://github.com/openstack/neutron/blob/master/neutron/tests/unit/db/firewall/test_db_firewall.py#L253 18:17:25 so we need to add delete rpc call or db call in the ut 18:17:51 nati_ueno: ok 18:18:01 https://github.com/openstack/neutron/blob/master/neutron/services/firewall/fwaas_plugin.py#L248 18:18:05 may be this one 18:18:13 RajeshMohan: i am bit confused 18:18:26 RajeshMohan: the test is failing because you expect that the router will not be deleted 18:18:29 so we can get service_pluging object, so call this function is reacy 18:18:45 RajeshMohan: however you are getting back a 204 18:18:50 RajeshMohan: isn't that the issue 18:19:15 SumitNaiksatam: Test case is failing because Firewall is not getting deleted 18:19:22 SumitNaiksatam: but router is 18:19:33 i am seeing this: MismatchError: 409 != 204 18:19:41 SumitNaiksatam: When the router delete is called, we check if it is part of service-context 18:20:11 When called from plugin, the firewall delete is not getting called 18:20:17 204 is wired.. It means router is deleted.. 18:20:17 its L843, where its checking deletion of the router 18:20:30 nati_ueno: yeah thats what i am thinking 18:20:54 SumitNaiksatam: We raise exception when router is deleted - which is 409 18:20:58 SumitNaiksatam: so, (case1) FW is deleted.. (case2) resource check code is broken 18:21:28 Anyway, let's use pdb. It will be clear 18:21:50 At least, current ut base class has a issue fw isn't deleted.. 18:21:52 SumitNaiksatam: nati_ueno: I traced though the pdb. resoruce check is working - firewall delete is not getting called 18:22:09 RajeshMohan: so, may be return code is wrong? 18:22:20 #link http://paste.openstack.org/show/72672/ 18:22:50 nati_ueno: when router is deleted and Firewall delete is not called by then, then 409 is correct 18:23:01 yeah, 409 is correct 18:23:07 nati_ueno: I am trying to see why firewall-delete is not called 18:23:10 RajeshMohan: but in that case router is not deleted , right? 18:23:32 SumitNaiksatam: At the end of test case, all resources are deleted 18:23:52 SumitNaiksatam: the failure is at the exit (of 'with') 18:24:11 RajeshMohan: but the exception trace shows that its failing on L843 18:24:13 SumitNaiksatam: with firewall { with router {} }} 18:24:51 it fails when router delete is called 18:25:13 I had pdb.set_trace() in delete_firewall which never gets called 18:25:41 IMO, it is not efficient discuss bug without the code running 18:25:48 this is happened only thorugh plugin-test case, db-test is fine 18:26:00 let's share the someones screen after this meeting 18:26:24 in DB-test case, I hit delete_firewall breakpoint, followed by router delete as expected (on exit) 18:26:53 ok 18:27:48 RajeshMohan: no_delete is False by default 18:28:11 SumitNaiksatam: yes 18:28:14 RajeshMohan: so it should delete 18:28:28 RajeshMohan: anyway more importantly, do you think you have a good handle on this? 18:28:44 SumitNaiksatam: I had pdb trace there and was about to run when the meeting started 18:28:49 RajeshMohan: ah ok 18:29:09 nati_ueno: sorry, didn't ask you before, you had pinged regarding this or something else? 18:29:18 SumitNaiksatam: I think so 18:29:23 SumitNaiksatam: This one 18:29:34 nati_ueno: so once this done, you are +2? 18:31:40 SumitNaiksatam: yes 18:31:58 SumitNaiksatam: let's talk with Mark about deal with this as an exception 18:32:11 nati_ueno: yes 18:32:38 RajeshMohan: if you can keep nati_ueno, akihiro and myself in close loop on the progress, that will be good 18:32:48 RajeshMohan: we can all help you 18:32:59 nati_ueno: sounds good? 18:33:07 SumitNaiksatam: I will need your help 18:36:37 SumitNaiksatam: yes 18:36:45 nati_ueno: thanks 18:36:47 i can help debug too 18:36:57 kevinbenton: great, thanks for jumping in 18:37:02 since i'm just staring at the gate today anyway 18:37:05 :) 18:37:37 RajeshMohan: perhaps do a google hangout with kevinbenton, it helps with a second pair of eyes 18:37:43 kevinbenton: i can sympathize 18:38:20 kevinbenton's patch was in the gate queue for almost 20 hours and then jenkins failed 18:38:29 so its back in the queue at the end 18:38:45 and he has the db migration is messed up 18:39:04 garyduan: you wanted to raise the update issue? 18:39:11 garyduan: or we can wait on that? 18:39:29 Well, I'd like to discuss it 18:40:01 garyduan: yes, please go ahead 18:40:11 garyduan: so what is the use case? 18:40:21 I wonder in everyone's use case, if PUT method is important 18:40:59 PUT is to modify service context of a fw after its creation 18:41:07 guys- I am back to debugging - will ping you later 18:41:51 RajeshMohan: yes, thats fine 18:41:58 garyduan: ok 18:43:06 so, that's my question, is PUT needed? 18:43:07 garyduan: so this may or may not be possible in all cases, right? 18:43:17 garyduan: i am just trying to understand 18:43:54 garyduan: so you are saying, we deploy the firewall with the router service context 18:44:01 SumitNaiksatam: it means, fw is associated with R1 and later admin want it to by applied on R2 as well 18:44:10 garyduan: ah ok 18:44:29 garyduan: what about you want to change from router to subnet context? 18:44:48 SumitNaiksatam: yeah, that's possible 18:45:21 So we may transition thru a point when the fw is not applied at all 18:45:37 SridarK: yes 18:46:11 Or in TAP mode, admin wants the fw to monitor another network 18:46:36 garyduan: i think that makes sense 18:46:45 garyduan: correct 18:47:09 garyduan: so what was RajeshMohan's concern? 18:47:16 garyduan: i suspect on the implementation? 18:47:47 SumitNaiksatam: yes. To support that, we need to do it in update_firewall 18:48:08 garyduan: thats fine, its not an API change, right? 18:48:11 SumitNaiksatam: and support it in reference design 18:48:42 garyduan: we already support update to a firewall 18:49:05 SumitNaiksatam: we can't update service context in this patch 18:49:12 garyduan: i believe what RajeshMohan's patch is not doing is it is not supporting update to the service context attribute 18:49:28 garyduan: yes, but that can be added as a follow up as well, right? 18:49:38 SumitNaiksatam: yes. 18:49:41 garyduan: without requiring any new resource or API changes 18:49:46 garyduan: SumitNaiksatam: in some sense the update is being addressed in the patch in something like a restart case 18:49:56 garyduan: good, thats what i wanted to get at 18:50:01 SumitNaiksatam: that's what Rajesh and I agreed on 18:50:27 garyduan SridarK : so my thinking is that the backend will support this update only in some cases 18:50:39 garyduan: but i agree with your use case 18:50:58 it is more of a side-effect and am not sure that it is done in the sense of an update of the service-context attribute 18:50:59 Well, that's not all I want to say :-) 18:51:00 garyduan: i was not part of the discussion you had with RajeshMohan, so i am not aware of his objections 18:51:32 garyduan: if his objections are to including in this patch, thats fine, because we always add that 18:51:50 no, on the contrary 18:52:15 garyduan: i also don't think have to delete the firewall and create a new one is a good idea in the use case you pointed out (router R1 to R2) 18:52:20 FW instance is a virtual thing 18:52:40 garyduan: yes 18:52:51 garyduan: well lets call it logical 18:53:01 garyduan: but i think thats what you mean 18:53:06 the user can create a new instance with the intended context 18:53:18 and either keep the old one or remove it 18:53:32 garyduan: yes 18:53:32 For backend, it's probably the same 18:53:41 garyduan: yes 18:53:44 but operational wise ... 18:54:00 garyduan: yes 18:54:06 the user might not like it 18:54:46 garyduan: so how about we consider this as a follow up patch, i don't see us making any changes to the current patch (if we had to we had to do it earlier) 18:55:05 garyduan: the current patch will have this limitation 18:55:24 SumitNaiksatam: we don't have to touch it in the patch 18:55:56 SumitNaiksatam: garyduan: In some sense our update is an overwrite 18:56:18 garyduan: yeah, but i am saying we can try and support your use case as well 18:56:55 SridarK: I guess this is what Rajesh calls it, stateless 18:57:06 yes 18:57:08 garyduan: agent is stateless 18:57:26 garyduan: so we are good on this topic for the current patch? 18:57:32 SumitNaiksatam: my original question is, is it everyone's use case? 18:57:50 it may work in some sense but there are will be corner cases to be sure - best if we pick this up as a separate patch 18:57:51 SumitNaiksatam: :-) 18:58:33 garyduan: the use case you mentioned made sense to me 18:58:43 garyduan: R1 to R2 18:59:01 SumitNaiksatam: or NET1, +NET2 18:59:39 garyduan: I too agree that this is a valid usecase - it is like a config change (on where the fw is applied) in the physical world 18:59:42 garyduan: could be (but more difficult to implement, and the nature of the firewall in those cases) 18:59:50 SridarK: yeah 19:00:15 SumitNaiksatam: so we agreed we _have to_ address it in a separate patch 19:00:43 SumitNaiksatam: implementation wise, there are tricky cases we need take care 19:02:04 garyduan: yes, need to hear from RajeshMohan, but you rationale made sense to me 19:02:10 ok we got end it here 19:02:12 thanks guys 19:02:20 ok bye all 19:02:23 #endmeeting