18:42:04 #startmeeting Networking FWaaS 18:42:04 Meeting started Wed Jun 11 18:42:04 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:42:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:42:07 The meeting name has been set to 'networking_fwaas' 18:42:21 #info agenda https://wiki.openstack.org/wiki/Meetings/FWaaS 18:42:30 #topic bugs 18:42:48 SridarK: thanks for the terrific work on following up with the bugs 18:42:57 hello all, i would be participating in the meeting 18:43:27 badveli: welcome! 18:43:33 thanks sumit 18:43:33 #link https://bugs.launchpad.net/neutron/+bug/1310857 18:43:36 SumitNaiksatam: no worries, thanks to enikanorov: for fixing the last one 18:43:41 badveli: hi 18:43:43 enikanorov: thanks 18:43:48 SridarK: link? 18:44:17 hello sridark 18:44:33 I need to say that fwaas team need to revisit and clarify state transitions for firewall objects 18:44:46 enikanorov: explain? 18:44:49 that was my impression from fixing that gate issue with firewalls 18:45:17 enikanorov: this is also an artifact of the being installed on all routers in the tenant 18:45:28 SumitNaiksatam: logic around state transitions is not always clear, it also not quite clear which objects could be updated/deleted from DB in which states 18:45:30 at least this previous issue 18:45:42 SridarK: yes, i responded to the private email thread yesterday saying pretty much the same 18:46:09 enikanorov: okay, i thought we only have state/status for the firewall resources 18:46:26 enikanorov: and that has a well defined state transition 18:46:35 hmm, ok 18:46:44 anyway i have changed it a little bit 18:46:47 with my latest fix 18:46:54 enikanorov: happy to revisit and fix anything that you may have discovered is inconsistent 18:47:01 enikanorov: link? 18:47:09 1 sec 18:47:14 enikanorov: sure 18:47:23 SumitNaiksatam: https://review.openstack.org/#/c/98956/ 18:47:30 enikanorov: thanks 18:48:34 enikanorov: i will take a look, this was approved before i noticed it (i am on personal leave right now) 18:48:52 SridarK: you seemed to have +1'ed 18:48:55 btw, SridarK thanks for your recent comment, it explains the issue to me 18:49:11 because I was confused of tempest-side of it 18:49:43 (tempest test waits for firewall to become ACTIVE, but apparently some other router appears and agent changes the status again) 18:49:45 SumitNaiksatam: yes - i think this is good as with the timing on us being joined at the hip with routers getting added 18:50:02 enikanorov: yes 18:50:20 SumitNaiksatam: btw I have not yet congratulated you (about the reason of your personal leave :P ) 18:50:35 enikanorov: np, thanks :-) 18:50:36 so my congratulations! :) 18:50:52 enikanorov: thanks, quite unexpected, so still coping with it 18:51:04 i mean, unexpected because it was early 18:51:15 5 weeks early 18:51:18 anyway 18:51:28 so i was again looking at: https://bugs.launchpad.net/neutron/+bug/1310857 18:51:38 i see, it's almost always unexpected (in general) :) 18:51:46 enikanorov: hahaha :-) 18:51:55 (even if you're expecting it) 18:52:00 enikanorov: yeah 18:52:12 enikanorov: nice one 18:52:18 the above is the only high priority bug 18:52:30 and the review has been sitting for some time 18:52:55 yes more comments were added 18:53:10 SridarK garyduan can you also look at: https://review.openstack.org/#/c/90575/ 18:53:13 SridarK: thanks 18:53:22 we need to contact the patch author 18:53:23 I will 18:53:36 and possilbly markmcclain since he has -2 18:54:58 I reported one bug in Horizon in firewall configuration page 18:55:10 garyduan: thanks, sorry i did not respond to that 18:55:17 garyduan: is it getting attention? 18:55:26 thanks for SridarK to locate a reviewer for it 18:55:41 garyduan: if not we can ping akihiro 18:55:49 amotoki: there? 18:55:50 The comment is to add test cases 18:56:06 garyduan: link to review patch? 18:56:15 https://review.openstack.org/#/c/96654/ 18:57:42 i took the liberty of adding amotoki to the review 18:57:55 garyduan: let us know if you dont get attention 18:58:05 thanks to abishek for reviewing 18:58:08 SumitNaiksatam: thanks 18:58:17 Sorry guys got bounced out 18:58:25 SridarK: np 18:58:33 garyduan: so u got the review 18:58:37 SridarK garyduan: any other bugs of immediate concern? 18:58:46 SridarK: i have added amotoki as well 18:58:56 SumitNaiksatam: ok 18:58:56 SridarK: yes, thanks. KC also reviewed it. 18:59:07 no 18:59:09 garyduan: ok 19:00:03 garyduan: ah nice to see KC particpating 19:00:10 we dont have a patch for https://review.openstack.org/#/c/90575/ 19:00:45 it has been claimed 19:00:49 but i dont see a patch 19:01:07 that said, this is working as designed 19:02:35 sorry i pasted the wrong link 19:02:52 i meant to say we dont have a patch for: #link https://bugs.launchpad.net/neutron/+bug/1323299 19:03:09 #link SumitNaiksatam SridarK to check with owner of https://bugs.launchpad.net/neutron/+bug/1323299 19:03:25 #action SumitNaiksatam SridarK to check with owner of https://bugs.launchpad.net/neutron/+bug/1323299 19:03:54 #action SumitNaiksatam SridarK garyduan to review https://review.openstack.org/#/c/90575/ 19:04:53 enikanorov: you assigned this to yourself: #link https://bugs.launchpad.net/neutron/+bug/1327057 19:05:04 enikanorov: are you planning on posting a patch? 19:05:09 SumitNaiksatam: sure 19:05:24 enikanorov: i mean i was just asking 19:05:46 enikanorov: i know you are swamped 19:05:58 enikanorov: if you dont have time let us know 19:06:00 but i'm still able to make some progress :) 19:06:44 enikanorov: nice :-) 19:07:00 ok we have few more bugs which we have not triaged, will do that 19:07:18 #action SumitNaiksatam to triage “undecided” bugs 19:08:03 #topic Juno Plan 19:08:06 #link https://wiki.openstack.org/wiki/Neutron/FWaaS/JunoPlan 19:08:39 SridarK_ garyduan yisun prad: i dont see that the above ^^^ has been updated 19:09:18 sorry, SridarK seems to have updated 19:09:46 sumit, can i look at 1327057 19:09:49 garyduan: i believe you are blocked on flavors discussion 19:10:14 badveli: sure, can you coordinate with enikanorov 19:10:24 i can work with enikanorov 19:10:25 SumitNaiksatam: right. 19:10:55 badveli is sitting next to me. :-) 19:10:58 badveli: i am sorry, i couldn’t decipher your name from the nick 19:11:08 garyduan: ah ok 19:11:34 sumit my name is vishnu, will follow up with enikanorov 19:11:37 garyduan: can you formally introduce badveli to the team? :-) 19:11:40 Yi also updated his blueprint about Service Object and patch 19:11:50 badveli: Vishnu welcome again 19:12:04 sorry guys some issue with my machine and keep getting bounced - 19:12:07 garyduan: one sec we will come to the individual blueprint 19:12:08 thanks sumit 19:12:14 SridarK: np 19:12:23 not sure if u asked me something 19:12:27 SridarK: we assigned you an action item nevertheless :-P 19:12:37 SumitNaiksatam: :-) 19:12:42 Vishnu will work with me and Yi, focusing on FWaaS effort 19:12:55 SumitNaiksatam, So regarding metering work i have the initial draft of the spec on ceilometer side https://review.openstack.org/#/c/95779/5 .. For HitCounts, Is Rajesh planning to look at it? 19:12:59 garyduan: thanks, thats great 19:13:20 prad: nice, can you please udpate the wiki page with the link 19:13:23 SumitNaiksatam, if you guys have time, would probably useful for us to meet up separate and decide whats feasible on FWaaS side for juno-2 19:13:25 prad: did u bring up the issue we discussed in the morn 19:13:31 i believe rajesh is not around 19:13:37 SumitNaiksatam, ok 19:13:44 prad: we can discussion here or in a separate meeting 19:13:47 prad: please go ahead 19:14:04 for one metric we discussed was the usage at the summit.. and i was looking to do that based on create/update events 19:14:15 prad: ok 19:15:01 but on ceilometer side, it would be tricky to handle these samples over a period of time 19:15:05 even with a transformer 19:15:10 #action prad to update https://wiki.openstack.org/wiki/Neutron/FWaaS/JunoPlan with spec links 19:15:33 as we need to grab a definite amount of samples to conclusive determine the usage and there is a chance collector service went down loosing samples 19:15:42 prad: one sec, from a process perspective, we will need specs for any work that needs to be done on the neutron side 19:15:52 so in the spec above, i dint add the usage, but would like to see the feasibility 19:16:01 prad: we can coordinate with Rajesh as to who should do it, you or him 19:16:07 prad: if you want to do it, thats great 19:16:08 sure 19:16:23 prad: sorry, i interrupted you on the usage part 19:16:37 SumitNaiksatam, if we can get the bw/connections info similar to how LBaaS is giving us on FWaaS side, that would be a goos start 19:16:52 if you see the metrics table in the spec, i have some info there 19:17:00 #action prad to sync up with RajeshMohan on hit counts, perhpaps suggest a separate meeting with the fwaas team 19:17:11 prad: that is tough 19:17:26 ok 19:17:32 prad: link to metrics? 19:18:01 SumitNaiksatam, https://review.openstack.org/#/c/95779/5/specs/juno/ceilometer-meter-fwaas.rst 19:18:05 #topic Ceilometer requirements 19:18:14 #link https://review.openstack.org/#/c/95779/5/specs/juno/ceilometer-meter-fwaas.rst 19:18:43 SridarK garyduan yisun: you have thoughts on capturing the usage? 19:18:56 SumitNaiksatam, also i see a few api calls that are already there on neutron side.. like list_firewall, list_fw_rule and list_fw_policy which would be useful in general to track a fw existence and bill users 19:19:07 prad: sure 19:19:39 SumitNaiksatam, so i can at least get started on implementing one of two on these lines.. the big ones are connections and bw 19:19:59 prad: ok thats good to hear, for that you dont need anything more on the fwaas side? 19:20:01 Probably not all counters can be retrieved easily from iptables 19:20:10 garyduan: yeah, my thinking too 19:20:32 garyduan: can we come up with something that is reasonable, perhaps not as detailed? 19:20:39 * but perhaps 19:20:46 SumitNaiksatam, for connections and bw.. i do need a call similar to retrieve_pool_stats on lbaas side 19:21:01 prad: yeah, sure i got that 19:21:18 prad: that will require more discussion 19:21:24 sure understand 19:21:30 prad: can we say that you have three sets of requirements 19:21:55 prad: there is one set which is already satisfied by the list_* calls 19:22:18 SumitNaiksatam, yea other two are usage and stats 19:22:19 prad: then there is the second one for which you need to support with the hit counts 19:22:26 yep 19:22:37 prad: and the third is the connection/bandwith tracking 19:22:52 prad: ok 19:23:07 prad: i think we will tackle them in that priority 19:23:21 prad: i find it difficult that we will get to the last one in Juno 19:23:27 yea ..i can get the first implemented on ceilometer side without waiting 19:23:32 prad: ok good 19:23:41 prad: thanks for the udpate 19:24:07 sure, if we can coordinate with Rajesh soon it would be helpful to make the plan clear for fwaas side 19:24:11 sure 19:24:14 and for joining the meeting, to make progress it will be nice if you can participate in these meetings, so we can give you the support you need 19:24:27 SumitNaiksatam, will do sir 19:24:33 SumitNaiksatam: i will also reach out to Rajesh to check 19:24:36 prad: sure, i can send out the email today (unless you or SridarK want to do it) 19:24:41 SridarK: sure go ahead 19:24:45 lets move on 19:24:51 thx 19:24:56 #topic Service objects 19:25:06 i think we can go a little over with our meeting time 19:25:11 yisun: there? 19:25:32 i know i asked a bunch of questions and yisun posted a new patch set 19:25:36 He is in meeting 19:25:41 garyduan: ok 19:25:43 I have been reviewing also 19:25:49 garyduan: you can proxy 19:25:52 SridarK: absolutely 19:26:03 SridarK: but i think you are in agreement with the spec 19:26:03 i am ok - just need clarification on service obj to service group 19:26:14 yes 19:26:24 now we are thinking 1 : 1 19:26:26 whereas i am still having a bit of an issue with there being so much overlap with the firewall rule 19:26:46 but can we effect a 1 : many (serve obj : src grp) later on 19:26:47 Sridar, Yi and me had some discussion on the spec, and we are in agreement 19:27:00 will there be a backwards compatibility issue ? 19:27:01 i am not sure that the neutron core team is going to be happy with the subsets of the attributes being defined in different places 19:27:38 Service group is optional 19:27:44 i am trying to come up with a more concrete suggestion 19:27:49 garyduan: that is fine 19:27:56 garyduan: but concern still stand 19:27:58 stands 19:28:01 current way of inputting protocol and port are still allowed 19:28:10 garyduan: i agree and understand 19:28:26 garyduan: i am trying to figure out if we can reuse existing definitions 19:28:42 does that make sense to the you guys or its just me? 19:28:55 SumitNaiksatam: by existing what do u mean ? 19:29:05 SumitNaiksatam: reuse? 19:29:08 SridarK: attributes in the firewall rule 19:29:33 SumitNaiksatam: hmm - u mean just add to the rule directly ? 19:29:36 i am not comfortable with the same attributes being defined in many difrerent places 19:29:57 SridarK: yeah, i am trying to think what is the good way to do that 19:30:21 SumitNaiksatam: you mean allowing protocol/port and service group at the same time? 19:30:59 garyduan: i am saying that there is lot of overlap between the firewall_rule and the service_object 19:31:59 Can we say, the current model is experimental, and we can plan to face out protocol/port setting in firewall rule? 19:32:27 Hmm! so one will always need to use a service group ? 19:32:34 garyduan: that will be challenging 19:32:50 SridarK: yeah good point, thats the concern 19:32:52 SridarK: service group and object 19:33:15 There will be predefined objects 19:33:31 I guess with service groups - most vendor implementions do have this overlap 19:33:39 can service object use a firewall_rule? 19:34:04 ignore if thats a dumb question 19:34:40 I am not sure. I will have to ask Yi 19:34:53 garyduan: ok 19:35:10 #topic FWaaS and DVR 19:35:29 did yisun manage to send the email to the mailing list 19:35:55 unfortunately, i could not respond to the thread he started in the team 19:35:57 He has been in the DVR meeting 19:36:02 garyduan: ok good 19:36:11 garyduan: and how is that shaping up? 19:36:30 garyduan: do we have consensus on an approach? 19:36:44 There is a way to support FWaaS with DVR 19:36:56 #action yisun to update team on FWaaS/DVR support 19:36:58 but performance and packet flow is quite complicated 19:37:04 so still in discussing 19:37:06 garyduan: great, thats good to hear 19:37:54 #action garyduan to check with yisun if service_objects can reuse firewall_rules in some way 19:38:40 #topic Open Discussion 19:38:41 by reusing, you mean translate existing protocol/ports to service object? 19:38:48 #undo 19:38:49 Removing item from minutes: 19:39:18 garyduan: i meant that we dont have to repeat the overlapping attributes in two places 19:39:43 really sorry guys i am having terrible connectivity today 19:40:03 SumitNaiksatam: I will discuss that with Yi 19:40:03 goal of the service object much more than the firewall rule 19:40:13 SridarK: np, you got back in time before we have you the next action item ;-P 19:40:21 if we go through the bp 19:40:22 badveli: i agree 19:40:28 :-) 19:40:30 badveli: i dont dispute that 19:40:50 but we still want to anchor to the FW rule ? 19:41:09 SridarK: i am just thinking loud 19:41:09 yes. 19:41:10 this is used to group 19:41:37 as per the bp 19:41:38 SumitNaiksatam: no good - best to hash out now 19:41:46 SridarK garyduan badveli: brain wave (based on what SridarK just said), what if we do attribute extension for firewall_rule? 19:42:24 oh just have an extension for this new attribute ? 19:42:30 but the service group can be thaught of like a container 19:42:32 SridarK: yeah 19:42:37 and be used by the firewall 19:42:44 rule 19:42:57 badveli: ah good point 19:43:02 let me think a little more 19:43:25 SumitNaiksatam: yes i agree with badveli - i think that is the intent 19:43:28 #action SumitNaiksatam to explore if any attribute extension can be used to support service_object 19:43:48 SumitNaiksatam: perhaps we can also continue more discussion offline 19:43:53 badveli SridarK: i agree my suggestion was turning the model on its head 19:43:55 sure 19:43:58 SridarK: yes 19:44:08 so we are 3 mins over time 19:44:21 #topic Open Discussion 19:44:31 SridarK: we dont have zones spec, so i skipped 19:44:34 SumitNaiksatam: i will get a zones review out real soon 19:44:35 anything else? 19:44:39 SridarK: thanks much 19:44:50 nothing much else 19:44:52 SridarK: but we really appreciate that you are prioritizing attention to the bugs 19:45:08 SumitNaiksatam: no worries - it has been "interesting" :-) 19:45:16 SridarK: we need to fix the existing issues even as we plan for new features 19:45:30 SridarK: i am sure, but happy that you are “enjoying” it :-) 19:45:35 SumitNaiksatam: agree 19:45:49 garyduan prad badveli: anything else you want to discuss? 19:45:56 SumitNaiksatam: perhaps i should not have said that :-) 19:46:16 SridarK: no i put words into your mouth :-P 19:46:16 prad: we will follow up more on this metering too 19:46:22 :-) 19:46:58 btw, i just wanted to say thanks all for your support in the past few days, it was challenging to say the least, and it continues to be so 19:47:19 SumitNaiksatam: is this time from the morning ur "relaxation" ? 19:47:23 :-) 19:47:28 :-) 19:47:36 now u have to get back to some really hard work now 19:47:41 i am not so much concerned about my relaxation 19:47:43 :-) 19:47:48 SridarK: :-) 19:47:58 all right thanks all, lets call it a wrap for today 19:48:06 Ok bye all 19:48:10 lots of AIs to deal with :-P 19:48:13 #endmeeting