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