18:03:55 #startmeeting Networking FWaaS 18:03:56 Meeting started Wed Feb 19 18:03:55 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:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:59 The meeting name has been set to 'networking_fwaas' 18:04:11 #topic gate and temptest testing 18:04:33 last week we again brought up the enabling FWaaS at the gate with the PTL 18:05:05 the current plan is that we are waiting for a final nod from the PTL on this thursday 18:05:41 So after that the tempest tests can get pushed up ? 18:06:18 SridarK: yeah, we need this to be enabled so that the FWaaS tempest tests can be run in the gate 18:06:26 EmilienM: there? 18:06:35 Hi al 18:06:47 RajeshMohan: hi, thanks for joining 18:07:01 EmilienM: posted the patch #link https://review.openstack.org/#/c/65744 18:07:02 Hi RajeshMohan: 18:07:12 which targets the FWaaS API 18:07:46 however there was already a patch posted by yair: #link https://review.openstack.org/#/c/64362 18:08:16 Hmm! yes that is what confused me 18:09:09 just wanted to check with EmilienM if his patch supersedes the other one 18:10:20 #action SumitNaiksatam to check with EmilienM, Yair and mlavalle regarding the FWaaS API patch 18:10:25 #undo 18:10:26 Removing item from minutes: 18:10:44 : #action SumitNaiksatam to check with EmilienM, Yair and mlavalle regarding the tempest FWaaS API patch 18:11:24 in addition we would need to add scenario tests as well 18:11:35 let me know if there is interest 18:11:53 and we can coordinate accordingly 18:12:08 Are we time barred for this already ? 18:12:21 SridarK: not that i am not aware of 18:12:31 SridarK: i think earlier is always better 18:12:54 ok so for tests the review cut off of Feb 18 does not apply ? 18:13:21 #action SumitNaiksatam to also check if there are cut off dates for tempests tests 18:15:00 anything more on gate or tempest tests? 18:15:32 SridarK RajeshMohan garyduan: once we enable fwaas in the gate, we will have to be on the lookout of any issues that may crop up and break the gate 18:16:11 ok will do 18:16:18 SridarK: thanks 18:16:20 ok 18:17:00 SridarK: so we need to be watching closely on the day we turn it on, and at least a couple of days after 18:17:11 garyduan: there? 18:17:43 ok - is there an email list or some thing to subscribe to to know if there is an issue 18:18:06 SridarK: not that i am aware of 18:18:27 ok 18:18:36 i think we should join the openstack-ci IRC channel 18:18:58 ok thanks SumitNaiksatam: 18:19:10 or rather chat room 18:19:14 SumitNaiksatam: Is there a way to run these tests manually - so that we know how to debug 18:19:28 RajeshMohan: good question 18:19:40 SridarK: i believe you documented at least some of this, right? 18:20:11 SumitNaiksatam: RajeshMohan: we can do the tempest runs manually 18:20:23 yes i had sent out an email to all on that 18:20:42 but now figuring out and debugging is some deep magic. :-) 18:21:03 I will invest some time on this 18:22:02 SridarK: thanks, can you post the wiki page link again? 18:22:41 https://wiki.openstack.org/wiki/Quantum/FWaaS/Testing 18:23:13 #link https://wiki.openstack.org/wiki/Quantum/FWaaS/Testing 18:23:18 SridarK: thanks 18:23:19 will keep updating that as we add more things into tempest with some of these new patches 18:23:50 np SumitNaiksatam: 18:24:27 ok next topic 18:24:43 i don't see garyduan so let's go to the fwaas insertion 18:24:51 #topic Service Insertion and Firewall 18:25:00 #link https://review.openstack.org/#/c/62599/ 18:25:10 RajeshMohan: thanks for updating the patch 18:25:13 I added unit tests to the patch 18:25:36 RajeshMohan: do we have the end to end flow working? 18:25:36 I believe I have good coverage - if not let me know 18:25:58 Yes - tested with service context and verified 18:26:05 RajeshMohan: nice 18:26:08 SumitNaiksatam: I will do more testing 18:26:11 tanks 18:26:19 *thanks 18:26:35 RajeshMohan: I had one suggestion on the validation 18:26:43 SumitNaiksatam: yes 18:26:57 RajeshMohan: currently we are passing the key_specs 18:27:07 routers, networks, etc 18:27:13 SumitNaiksatam: yes 18:27:29 this is good in a way since its flexible 18:27:58 however, it also introduces the possibility of some service introducing a context that is different from the others 18:28:24 SumitNaiksatam: ok 18:28:30 i was thinking that if we don't pass the key_specs but embed the validation inside the validation method, it will be good 18:28:52 that way, if some service wants to pass something else, they will have to modify the validation method 18:28:59 and is more apparent during the reviews 18:29:20 and also we have one place which clearly enumerates all the supported contexts 18:29:31 SumitNaiksatam: when you some other service - you mean like vpnaas, lbaas? 18:29:43 yeah, or any others in the future 18:30:12 SumitNaiksatam: so u mean that the keyspecs is just a string 18:30:13 perhaps, the key specs can be defined as constants in the attributes module 18:30:19 SumitNaiksatam: I am ok with that - I did this foe flexibility (as you mentioned) 18:30:38 the key specs is optional right? 18:30:46 SumitNaiksatam: Yes 18:31:03 so i was thinking that we don't use it 18:31:32 instead always check against a fixed list of strings (routers, networks, subnets, ports) 18:31:36 SumitNaiksatam: I thought -not requiring to change attribute file - will be a good thing 18:31:49 SumitNaiksatam: but if you think it helps in reviews, I can make the change 18:32:23 RajeshMohan: at this point i am not sure what others think, i am coming from the perspective of there being a standard contract for all services 18:32:46 it makes it easier from the user's standpoint to understand the semantics 18:33:47 do you guys agree? 18:34:00 Hmm i still a bit on the wall 18:34:11 it is more flexible for sure 18:34:33 but potentially some anbiguity for the end user 18:34:57 SumitNaiksatam: in service context chain - some common definition of all possible service context makes sense 18:35:08 RajeshMohan: thats a good point 18:35:15 SridarK: yeah 18:36:46 SridarK: thanks for posting the CLI patch 18:37:08 RajeshMohan: you had some issues with using the CLI? 18:37:41 SumitNaiksatam: No worries - i am doing the validation for now - but we can discuss ur suggestion to defer resource validation to the backend 18:37:43 SumitNaiksatam: yes I tried and it did not work for me - send email to Sridar 18:37:58 okay 18:38:18 RajeshMohan: before that, garyduan had some concerns on the terminology and the db model 18:38:24 SumitNaiksatam: RajeshMohan: I tried to check on the msg formatting to make sure that it is aligned with the backend 18:38:31 still debugging some UT issue 18:38:49 SridarK: thanks, let us know when you think its working 18:38:57 will sync with RajeshMohan: on this patch and then make sure it works 18:39:01 RajeshMohan: earlier question 18:39:04 *his 18:40:23 SumitNaiksatam: you mean the review comments from Gary 18:40:35 SumitNaiksatam: or was there some offline comments? 18:40:36 as regarding service_context versus insertion_context, that evolved from a discussion with nati_ueno 18:41:12 SumitNaiksatam: yes 18:42:19 SumitNaiksatam: I saw the review comments - I will follow up with Gary. Was busy with unit tests 18:42:26 RajeshMohan: ok 18:42:52 i believe service_context terminology should be good 18:43:41 there was a suggestion on reducing the number of tables 18:43:57 SumitNaiksatam: I liek service_context 18:44:29 SumitNaiksatam: there is many-to-one relation. THat was one of the reasons for multiple table 18:44:55 SumitNaiksatam: Gary's comments were not complete - atleast I could not see how it would be done with one table 18:45:02 RajeshMohan: yeah, i am not sure we can group everything into the same table 18:45:06 SumitNaiksatam: I will get more information from him 18:45:10 RajeshMohan: let me think about it as well 18:45:12 RajeshMohan: thanks 18:45:43 #action RajeshMohan to follow up on garyduan's comments on reducing the number of tables 18:46:04 RajeshMohan: we don't need any devstack changes, right? 18:46:13 RajeshMohan: default is still all routers 18:46:15 SumitNaiksatam: yes - not changes 18:46:24 SumitNaiksatam: I mean, no changes 18:46:25 RajeshMohan: ok 18:46:33 anything more to discuss on this? 18:47:20 #topic service_type framework 18:47:30 #link https://review.openstack.org/#/c/60699 18:47:40 i believe garyduan is still not around 18:47:47 he posted a new patch with more UTs 18:48:01 SridarK RajeshMohan can you take a quick look at his patch? 18:48:22 RajeshMohan: you might also need to rebase your patch (it shows that its out of sync) 18:48:35 I rebased last night 18:48:41 let me check 18:48:43 SumitNaiksatam: will do - was tied up with the CLI stuff but will review now 18:48:45 RajeshMohan: ah ok, i probably checked before that 18:49:08 RajeshMohan: it currently says outdated 18:49:14 SridarK: np 18:49:21 SumitNaiksatam: It is current 18:49:38 SumitNaiksatam: oh 18:49:45 SumitNaiksatam: I did not refresh 18:49:49 on gerrit it says outdated 18:50:09 SumitNaiksatam: I will rebase in next 30 min 18:50:16 RajeshMohan: np, take your time 18:50:29 RajeshMohan: amotoki has some comments on garyduan's patch 18:50:55 RajeshMohan: perhaps we can expect the same for your patch as well, so we can preempt those 18:51:25 SumitNaiksatam: I will look at those comments 18:51:31 RajeshMohan: thanks 18:51:53 i don't think Yi is here either 18:52:04 #topic Open Discussion 18:52:28 anything more to discuss today? 18:52:36 or we can get a few minutes back 18:54:32 btw, there are some discussions going on in the context of group policy that require service insertion/chaining 18:54:44 i have pointed to RajeshMohan's patch 18:54:53 you guys can also chime in 18:55:04 ok thanks guys, bye! 18:55:12 #endmeeting