18:31:27 #startmeeting Networking FWaaS 18:31:27 Meeting started Wed May 6 18:31:27 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:31:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:31:31 The meeting name has been set to 'networking_fwaas' 18:31:42 hi 18:31:49 any announcements any one wants to share? 18:31:51 pc_m: hi 18:32:19 #topic Bugs 18:32:40 hi 18:32:56 sballe: hi 18:33:07 we still have the high priority doc bug 18:33:19 SridarK: thanks for posting the new patch set 18:33:45 SumitNaiksatam: no worries - sorry learning this stuff :-) 18:33:56 SridarK: badveli any other critical/high show up on your radar? 18:34:01 SumitNaiksatam: also thanks to pc_m for review and Diane F for fixing things 18:34:16 SumitNaiksatam: nothing from me 18:34:42 pc_m: thanks as always 18:34:52 yeah did notice diane posting immediate fixes 18:34:59 sure np 18:35:06 is yushiro here? 18:35:27 sorry i did not follow up on #link https://review.openstack.org/#/c/176589/ 18:35:58 SridarK: do you know why the Cisco CI failed on this? 18:36:31 SumitNaiksatam: not sure - i will follow up on this 18:36:50 SumitNaiksatam: i don't think we should have any impact with the change 18:36:51 SridarK: thanks 18:37:19 np at all 18:37:20 seems like there are lot of bugs related to FWaaS when using REST API...seeing that pattern 18:37:23 any other bugs to discuss? 18:37:38 vishwanathj: “lots” of bugs? 18:37:51 lots ==> 2 to 3 :) 18:38:04 vishwanathj: i think those or validation bugs 18:38:09 or -> are 18:38:19 adding tighter validation to existing cases 18:38:33 i am referring to a couple of those filed by yudhiro 18:38:38 *yushiro 18:38:55 that's how I know that there are 2 or 3...yushiro has been finding them 18:39:11 vishwanathj: but sorry to stop you, did you have a follow up comment to that? 18:39:40 I was going to ask if we are lacking tests 18:40:14 vishwanathj: i think in general more test cases is always desired 18:40:15 so that we can look at it from that angle during reviews for future code commits 18:40:35 ok 18:41:04 very few projects would be able to say - we are completely covered on the tests :-) 18:41:04 no more comments from me 18:41:17 agreed 18:41:20 so yes definitely, any effort to add test coverage will be very much appreciated 18:41:31 i am also seeing this as a positive thing that more folks are looking at FWaaS 18:41:39 SridarK: true 18:41:42 true 18:41:55 yeah the more people beat it, the more things will be uncovered 18:42:04 ok if nothing more on bugs, lets move on 18:42:29 oh before we move on, SridarK is the doc patch complete, or do you need help with wrapping it up 18:42:39 i am asking because vishwanathj was offering to help yesterday 18:42:58 SumitNaiksatam: thanks - i think i am good - i am hoping to get the policy and rule stuff pushed up today 18:43:23 SumitNaiksatam: will definitely need validation once that happens to make sure all attributes are covered 18:43:42 SridarK: thanks 18:43:47 SumitNaiksatam: but i will shout out if i need some help :-) 18:44:00 easy way to review for the rest of the team would be to look at the rendered docs 18:44:08 rather than reading the source 18:44:21 this has been a pattern match and reproduce experience :-) 18:44:52 SridarK: :-) 18:44:55 ok moving on 18:45:07 #topic Liberty Features 18:45:33 last week i requested the team to update participate in updating the wiki #link https://wiki.openstack.org/wiki/Meetings/FWaaS 18:46:07 i would hope that as we propose more features they get added to: #link https://wiki.openstack.org/wiki/Meetings/FWaaS#Blueprint_Tracking 18:46:39 FWaaS Rules Direction: #link https://review.openstack.org/#/c/171340 18:46:50 slaweq: over to you 18:46:54 yep 18:47:03 I'm here 18:47:14 have You got any questions or sugestions about that? 18:47:17 slawek hi - had one query for discussion 18:47:49 yes? 18:48:07 SridarK: please go ahead 18:48:07 slaweq: was wondering if had thoughts abt the direction being associated with a collection of rules as a policy or as a firewall 18:48:33 i hope we didnt lose anyone in the split 18:49:03 slaweq: full disclosure: as our vendor implementation we associate direction with the firewall to say " i want the firewall to be applied on all ingress traffic or egress traffic" 18:49:05 I didn't think about it 18:49:41 slaweq: i am okay with what u have - but wanted to ask if that would make sense as well 18:50:09 fwaas folks here ? 18:50:16 I don't know, I was thinking about it more like about of iptables for example 18:50:18 SridarK: i am still here :-) 18:50:22 :-) 18:50:29 some problem, but i am here 18:50:38 so You can apply rule to specify "chain" by setting direction on it 18:50:40 sorry some activity going on at least as i see it in my viewer 18:50:53 yeah, there was a network split 18:50:56 i am still here....but saw a bunch of people leave in batches and join in batches 18:51:05 slaweq: just a thought to discuss if it makes sense and evaluate 18:51:06 yes 18:51:21 * pc_m not here mentally :) 18:51:24 anyway, please continue, i think we did not lose anyone 18:51:28 pc_m: lol! 18:51:38 + for iptables 18:51:40 ok, so You think about something like "ingrees policy" and "egress policy" 18:51:44 slaweq: i will post on the review - but thought we can do a quick discussion here too 18:51:46 instead of rules 18:52:08 slaweq: we don't have that notion on policy - we have single policy model 18:52:16 SridarK: is it something you envision as an additional feature to what you slaweq has already proposed? 18:52:25 but sort of to say "lets FW all ingress traffic" 18:52:26 or is it instead 18:52:46 SumitNaiksatam: no just looking at the notion of direction being applied at the rule level 18:53:18 imho if you want to firewall all ingress traffic You can put rule to allow all egrees and rules to filter ingress traffic 18:53:21 for example 18:53:58 slaweq: yes for sure 18:54:40 slaweq: in your observation the granular usage in more prevalent? 18:54:47 slaweq: just the question of granularity, the opposing argument as in ur proposal would be in a policy u may want some rules to be for ingress some for egress 18:54:48 in -> is 18:55:20 SridarK: just to clarify, did you mean associating the direction with a firewall policy or a firewall? 18:55:26 slaweq: the granular is more flexible, just to dot the i's i ask the question 18:55:34 SumitNaiksatam: yes exactly 18:55:39 i mean in the context of the vendor implementation 18:55:55 SumitNaiksatam: yes 18:56:07 SridarK: Did you mean associating direction to a bundle of rules? 18:56:13 for our model, firewall can be associated with exactly one policy, so if effectively the direction is on the firewall (if its associated with policy) 18:56:31 vikram__: yes was asking if that is something that would make sense 18:56:44 SumitNaiksatam: yes exactly 18:57:07 okay lets post the comments on the review 18:57:21 slaweq: i am ok with the proposal - just wanted to bring up the discussion and to get ur thoughts 18:57:23 slaweq: sorry it took longer to get to this stage of the discussion 18:57:24 but in the current model how to achieve it? 18:57:24 but IMHO if direction will be associated with policy or firewall instead of rules then You can't filter some ingress and some egress traffic, yes? 18:57:54 slaweq: yes - u are correct 18:58:26 if firewall could have more than one policy then it may sense for me 18:58:43 i think garnular definitely affords more flexibility, however from a usage perspective it might also be easier to define the direction for the policy (rather than having to apply inidividually, assuming that is a predominant use case) 18:58:49 slaweq: definitely more flexibility - just wanted to look at it from a typical usage point of view 18:59:06 sumit: +1 18:59:54 ok moving on to badveli’s spec and patch: #link https://review.openstack.org/#/c/94133 19:00:02 slaweq, let me know if you need any help in coming up with Horizon blueprint and Horizon code for this? 19:00:09 slaweq: sorry for bringing this up late - intent is not derail - just to make sure we have covered all aspects 19:00:30 vishwanathj: thx, I will contact with You about it 19:00:34 SridarK: good point to bring up though 19:00:59 SumitNaiksatam: should have asked even earlier - brain needs more recharging :-) 19:01:01 SridarK: it's ok for me :) great that You are asking about it 19:01:01 slaweq: +1, vishwanathj indeed thanks for offering to help out, thats great! 19:01:17 badveli: there? 19:01:20 yes 19:01:33 ok guys, I really have to leave now, thx for talking about my BP 19:01:37 were you able to repurpose your spec for liberty? 19:01:51 slaweq: thanks a bunch for joining, we will got to gerrit for your spec 19:02:04 not yet sumit, 19:02:10 badveli: ok 19:03:00 sumit, is some one already did the same it might be easier for me to talk 19:03:18 to them and get this quickly 19:03:30 badveli: i havent checked off late, but you can look at the commits on the neutron-specs tree 19:03:37 last week i also brought up the topic about updating the “project plan” wiki page 19:03:46 based on the features we are working on 19:03:48 thanks sumit 19:04:11 vikram__: perhaps you can update in the context of the firewall rules direction 19:04:18 #link https://wiki.openstack.org/wiki/Neutron/FWaaS/LibertyPlan 19:04:31 SridarK: are you planning to add the zones spec? 19:04:33 sure 19:04:41 vikram__: thanks 19:04:43 SumitNaiksatam: yes will do so 19:04:55 And update - 19:06:03 SridarK: there? 19:06:09 SumitNaiksatam: yes 19:06:26 oh i thought you were saying there is an additional update in that context :-) 19:06:40 SumitNaiksatam: sorry - i thought my link bounced :-) 19:07:12 SumitNaiksatam: no i will add the spec and update the link - need to close on some issues - some thinking prompted some my questions on the direction spec too 19:07:20 vishwanathj: i believe you were also interested in this, so you and SridarK can sync up 19:07:40 SumitNaiksatam: yes we bounced some ideas on this 19:07:48 any other features that anyone wants to bring up? 19:07:53 SumitNaiksatam, definitely would like to work under SridarK guidance 19:08:22 vishwanathj: will ping u and Karthik for some more thoughts too 19:08:24 SridarK, let me know if we need to have additional conversation 19:08:32 ok 19:08:39 vishwanathj: :-) yes 19:08:57 anyone planning any other features for Liberty? 19:09:30 yamahata: you had mentioned L4-7 classification and filtering 19:09:43 yamahata: any update on the refernce implementation candidates? 19:09:55 SumitNaiksatam: i think yushiro also had some thoughts but i think he is traveling 19:10:23 SridarK: oh okay, hopefully he will be at the design summit 19:10:34 SumitNaiksatam: yes i think he will be there 19:10:38 nice 19:10:54 perhaps yamahata is not around 19:11:02 #topic Vendor drivers 19:11:23 any planned changes to the vendor drivers during liberty? 19:11:34 if so please update: https://wiki.openstack.org/wiki/Neutron/FWaaS/LibertyPlan 19:11:42 SumitNaiksatam: would vendor stuff come out of the main tree in L ? 19:11:45 so that we can track the reviews and progress of the patches 19:11:58 SridarK: i dont know 19:12:23 pc_m: do you know if we are pulling out the vendor drivers from *aas in liberty? 19:12:38 SumitNaiksatam: ok - will be interesting to see if we follow as for neutron 19:12:41 SumitNaiksatam: Haven't heard anything 19:13:07 SumitNaiksatam: I'm looking at pulling Cisco VPN drivers out, but no community drive to do that. 19:13:32 pc_m: i was not aware of either 19:13:59 pc_m: you feel that its a better model to pull the vendor driver out? 19:14:51 SumitNaiksatam: yeah, gives vendor ability to modify independent of community work, and in VPN there are so few people and cores to review that it'll be easier for vendor to get approvals. 19:15:12 pc_m: completely understand 19:15:58 one advantage of being in tree when there are smaller number of drivers is that its easier to keep the drivers in sync with changes in the project 19:16:06 they get more attention 19:16:20 SumitNaiksatam: yes the breakages are more obvious 19:16:33 but one can also argue that with a good functional 3rd party CI you can catch things quickly 19:16:46 anyway 19:17:05 #topic Functional Tests 19:17:15 badveli: any progress in your exploration? 19:17:31 just started putting things 19:17:35 badveli: nice 19:17:39 tried an experiment code 19:17:44 badveli: nice 19:17:46 in unit tests 19:17:49 directly 19:17:56 badveli: okay 19:17:57 using name space ping 19:18:22 try to set up the actual rules instead of mock 19:18:48 by using the snat name space 19:18:53 badveli: with a view to making concrete progress, and faster, can i suggest that (a) you document your exploration on the wiki page 19:19:08 (b) if you can post a WIP patch with the test code you have written 19:19:09 yes, i can do that 19:19:21 that way other folks can also jump in and split the work with you 19:20:14 badveli: thanks for the update 19:20:16 #topic Open Discussion 19:20:20 thanks sumit 19:20:30 You may want to look at VPN functional test for ideas. 19:20:33 vikram__: were you able to get your devstack setup going with kilo? 19:20:54 thanks pc_m, i will take a look 19:20:59 badveli: pc_m is a great help 19:21:11 nothing committed yet, but out for review. 19:21:13 yes thanks pcm_m 19:21:37 badveli: https://review.openstack.org/159746 19:21:42 pc_m has been blazing the trail in this regard, so please take his guidance 19:21:45 i will take an example that will make my life easier 19:21:48 pc_m: thanks 19:22:15 I did a bunch to setup fucntional tests to not stack devstack, but instead to do like Neutron and just configure. 19:22:46 do we need to sync up on anything with regards to planning for the Liberty design summit sessions? 19:22:49 That commit is https://review.openstack.org/168115 19:22:57 pc_m: thanks 19:23:09 SumitNaiksatam: should we set a time where we can meet around a table at Vancouver ? 19:23:09 SumitNaiksatam, FYI: pc_m and I had a quick chat regarding notification registration in FirewallService object.....a bug should be sufficient to track this was our conclusion. I will take the action item to open the bug and work with pc_m to deliver a code fix in liberty. 19:25:06 vishwanathj: great, thanks for the update (please feel free to add it to the agenda for future tracking) 19:25:12 SridarK: +1 to that 19:26:57 anything else to discuss today? 19:27:11 SumitNaiksatam: no i am good 19:27:34 anyone else want to bring up anything? 19:27:59 nothing from my side 19:28:03 alrighty, thanks all for joining! 19:28:04 You guys meeting next week? 19:28:10 oh yeah just wanted to ask 19:28:18 shall we skip next week’s meeting? 19:28:28 and meet directly at the summit? 19:28:34 SumitNaiksatam: sure okay bye me - 19:28:34 sounds good to me 19:28:44 bye all 19:28:49 bye 19:28:49 okay, so i will send out an email to -dev 19:28:58 pc_m: thanks for bringing that up ;-) 19:29:09 alright, bye all! 19:29:10 bye all 19:29:14 see you in vancouver! 19:29:19 bye! 19:29:26 #endmeeting