18:36:35 #startmeeting Networking FWaaS 18:36:36 Meeting started Wed Jun 18 18:36:35 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:36:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:36:39 The meeting name has been set to 'networking_fwaas' 18:36:44 #info agenda https://wiki.openstack.org/wiki/Meetings/FWaaS 18:36:53 #topic bugs 18:37:19 #undo 18:37:20 Removing item from minutes: 18:37:26 #topic Action item review 18:37:51 i basically copy pasted the action items from last weeks meeting 18:38:02 #link https://wiki.openstack.org/wiki/Meetings/FWaaS#Action_items_from_previous_meeting 18:38:24 do we need to discuss any of them first? 18:38:42 i think we accomplised some of them 18:39:42 i have updated the plan with some vendor stuff as well 18:39:51 beyounn: perhaps you can do the DVR udpate as a separate agenda item 18:39:55 SridarK: sure, thanks 18:40:03 and talked to Rajesh as i mentioned in email 18:40:06 Same here 18:40:19 so we may need to plan for prad's requirements 18:40:41 beyounn: you mean you updated the wiki page? 18:41:04 SridarK: yeah, lets discuss that as a separate item, thanks for the follow up with rajesh 18:41:05 Sumit: right, for the DVR, there are no progress in past two or three weeks 18:41:11 beyounn: ok 18:41:22 beyounn: your plan was to send an email to the -dev mailer? 18:41:29 Sumit: it is mainly be cause I'm too busy to follow it up 18:41:30 beyounn: just for the record 18:41:44 Sumit: I will kick out the email to ML 18:41:46 beyounn: i can totally understand 18:41:57 beyounn: nice, at least that way it will be on whoever’s radar 18:42:09 Sumit: right 18:42:16 #action beyounn to send DVR issues related to -dev mailer 18:42:25 Sumit: I will try to do it this evening 18:42:31 beyounn: thanks much 18:42:39 #topic bugs 18:43:13 so our bug count is increasing: #link 18:43:16 #link https://bugs.launchpad.net/openstack/+bugs?field.searchtext=fwaas&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package 18:43:29 and we have quite a few untriaged bugs 18:43:38 i had the action item to triage them but has not happened 18:44:21 i brought this one up in the neutron IRC meeting: #link https://review.openstack.org/#/c/90575/ 18:44:29 since it has a -2 from markmcclain 18:45:06 in parallel we also need to reach out to the owner of this patch 18:45:13 SumitNaiksatam: yes good - i was out on Mon and could not make the mtg 18:45:26 SumitNaiksatam: ack (sorry, had to step out for a phone call) 18:45:32 i think the comments there are valid - not sure if this is the approach on the fix 18:45:37 SridarK: yes, i brought up two things, this bug, and beyounn’s service objects spec 18:45:59 does anyone know the owner of this patch? 18:46:15 SumitNaiksatam: seems to be enovance - i can also send an email 18:46:34 SridarK: okay that will be good if you can follow up 18:46:41 SumitNaiksatam: will do 18:47:03 #action SridarK will follow up with owner of https://review.openstack.org/#/c/90575/ 18:47:42 does anyone else want to pitch in with triaging the New and Undecided bugs in the link above? 18:47:53 SumitNaiksatam: i can take a shot 18:48:34 SridarK: great, thanks again 18:48:55 SumitNaiksatam: will be a bit slow next 2 days though 18:49:04 #action SridarK SumitNaiksatam to triage new/undecided bugs in the next couple of days 18:49:14 SridarK: oops said that too soon, np 18:49:47 SumitNaiksatam: no worries need to wrap on vendor bp - but should be done soon 18:50:13 i think you all already chimed in on #link https://review.openstack.org/#/c/99956/ 18:50:49 i have not seen an update to that patch 18:50:59 yes i am not sure this is the right approach as u have also mentioned 18:51:11 jlibosva: ping 18:51:35 SumitNaiksatam: hi 18:51:52 jlibosva: hi, we wanted to check with you on #link https://review.openstack.org/#/c/99956/ 18:52:04 jlibosva: the fwaas team has commented 18:52:14 SumitNaiksatam: yeah, I was about to ask what will be the correct approach 18:52:37 jlibosva: this needs to be handled on the agent side 18:52:49 i think SridarK put a more specific comment to that effect 18:53:09 SumitNaiksatam: so l3 agent will contact neutron-server and that will set different status of FW or fail the creation? 18:53:24 jlibosva: yes and it is handled when a new router is added 18:53:51 jlibosva: no it will not fail the creation - will be in PENDING 18:54:20 SridarK: but that's confusing for user 18:54:31 and when router is added will go to ACTIVE 18:54:36 aha 18:55:04 but I still think it would be nice to let user know that he needs to have a router 18:55:10 jlibosva: yeah, those are already handled 18:55:17 jlibosva: i agree that it is confusing but as we move to the insertion model - we will get away from this 18:55:50 jlibosva: yes, as SridarK mentions this is more an issue with not beig able to provide a service insertion context 18:56:07 jlibosva: so by default we try to apply the firewall on all the routers 18:56:30 jlibosva: or any routers that will be created later 18:57:19 SumitNaiksatam: should I understand it that nothing can be done at this point until the service insertion bp is ready? 18:57:52 jlibosva: what we have currently is working as designed 18:58:11 jlibosva: thats as much as we can do without the service insertion 18:58:22 jlibosva: the notion of the pending state is used in other services too 18:58:22 SumitNaiksatam: got it, thanks 18:58:34 jlibosva: so i believe the user should be familiar with this 18:58:51 jlibosva: if the documentation is not clear, i think we should definitely address it 18:59:22 in general, i think the issue when the router or interface is deleted in probably not being handled 18:59:24 SridarK: can you confirm 18:59:38 SumitNaiksatam: yes 19:00:15 and again we will probab rework those areas with serv insertion 19:00:43 jlibosva: i believe there is a log msg on the agent side to this effect 19:01:15 ok, thanks for the help 19:01:18 SridarK: but i beleive we need to set the status to pending, if all the routers go away, right? 19:01:31 jlibosva: let me point that out - perhaps if it is not sufficient - we can improve it but we cannot really do much on the plugin side 19:01:51 SumitNaiksatam: i believe so 19:02:24 SumitNaiksatam: i will double check that to be sure - 19:02:28 SridarK: i think there is a bug to that effect 19:03:34 SumitNaiksatam: the router going away had an issue to deal with it - will need to refresh my memory - at that point we discussed this - just don't recall exactly now 19:03:46 SridarK: ah ok 19:04:11 #action SridarK to revisit discussion on router delete 19:04:28 i am also waiting for the owner of #link https://bugs.launchpad.net/neutron/+bug/1323299 to post a patch 19:04:29 SumitNaiksatam: the all routers makes it difficult to enforce any foreign key type constraints on delete of routers 19:04:40 SridarK: ok 19:04:59 does any one else want to take a crack at the above issue? 19:05:10 garyduan beyounn: is Vishnu around? 19:05:15 yes 19:05:19 SumitNaiksatam: on that bug there was a response on the ML 19:05:24 badveli: hi 19:05:29 hello sumit 19:05:35 SridarK: which one? 19:05:56 and according to Rajesh - not sure if we can do anything on this (132399) Floating ip 19:07:34 typically, firewall should be applied before dnat 19:07:51 Did Rajesh say if it can be done or not? 19:08:05 garyduan: i think he mentioned cannot 19:08:34 garyduan badveli: do you want to explore the feasibility of that one? 19:08:51 actually this is working as designed 19:08:55 we did not intend to support this 19:09:03 at least in the first iteration 19:09:10 now we need to explore if we can 19:09:12 From Rajesh: "The chain we install will only see private addresses. So, one needs to use internal IP address in that rule. " 19:09:41 SridarK: yes, because i believe the ip address is not dnated already when we apply the firewall 19:09:56 SumitNaiksatam: true 19:10:15 SridarK: so we never see the floating up 19:10:17 *ip 19:10:45 SumitNaiksatam: yes we are always on fixed ip 19:11:06 okay so no one wants to look at this 19:11:14 garyduan: badveli - will add u to the email that Rajesh sent 19:11:46 SumitNaiksatam: we can look at it together with service group backend 19:11:52 i suspect that some of the undecided bugs might turn out to be higher priority 19:11:58 garyduan: ok 19:12:11 so we need to triage them at the earliest 19:12:48 #topic blueprint tracking 19:12:59 so regarding service objects 19:13:22 unforntunately i was not able to follow up with the team on this, and my apologies 19:13:32 has any more discussion happened on this since the last meeting? 19:13:49 Sumit: thanks for the comments 19:13:50 beyounn and myslef send an email clarifying 19:13:51 badveli and beyounn: i know you guys had posted emails 19:13:59 badveli: yes 19:14:28 i will try and respond to that the earliest, again apologies 19:14:34 Sumit: for your comments, how about I add icmp support to rule as well? 19:15:04 beyounn: yeah my point was that we might need to add icmp support regardless of service objects 19:15:17 Sumit:agree 19:15:39 Sumit: only one questions-- is it ok to overload source/dest ports for code/type? 19:16:01 beyounn: you ask because security groups does it? 19:16:07 Sumit: right 19:16:17 I don't really want to do it that way 19:16:21 beyounn: i did not quite understand why they did it that way 19:16:24 beyounn: yeah 19:16:40 beyounn: its not intuitive to me at all 19:16:43 Sumit, ok, I will propose the new attributes in firewall rule 19:16:57 beyounn: ok sounds good, what do others think? 19:17:17 This is good - std ACL type definition ? 19:17:30 SridarK: ok 19:17:38 --protocol icmp --icmp-type 1 -icmp-code 1 19:17:44 ok ? 19:17:47 eys 19:17:51 *yes 19:17:58 beyounn: that sounds very intuitive to me 19:18:19 And it is consistent with service object as well 19:18:26 beyounn: ok 19:18:38 SumitNaiksatam: should this go as a separate BP ? 19:18:48 SridarK: ah good point 19:18:56 SridarK: i was thinking when i was putting that comment 19:19:02 ideally yes 19:19:03 sigh i hope the answer is No :-) 19:19:25 I was afraid that u would say yes :-) 19:19:39 well if i dont, someone else will 19:20:03 Is a separated BP really necessary? 19:20:05 this should be a straighforward one though to review as a spec 19:20:08 True that is the right way as this has nothing to do with serv obj 19:20:14 beyounn: ok lets think a little more 19:20:30 beyounn: as SridarK said 19:20:52 beyounn SridarK: i am definitely not in favor of creating more work than required 19:21:05 should i file a bug that icmp is broken on firewalls ? :-) 19:21:09 and would hope to cut the process as much as possible 19:21:23 Sridark +1 19:21:41 And I can take the bug 19:21:49 :-) 19:22:02 so while on that, have you seen this #link https://wiki.openstack.org/wiki/NeutronJunoProjectPlan 19:22:09 neutron juno plan ^^^ 19:22:14 this does not have fwaas at all 19:22:19 so i have reached out to the PTL 19:22:25 i believe that is an oversight 19:22:40 and i would be sending him the items which need to be listed 19:23:02 SumitNaiksatam: yes 19:23:04 that said, you can see that the number of items mentioned for the other services are minimal 19:23:16 and so we cannot give a laundry list either 19:23:54 we have to decide what is it that is absolute top priority for us, and for which we would want to get a committment from the PTL to get on the roadmap for Juno 19:23:55 hopefully, we get flavor settled 19:24:07 garyduan: just saying that 19:24:18 garyduan: thanks, so thats a given 19:24:33 is prad_ around? 19:24:33 SumitNaiksatam: perhaps we can do some discussions offline and try to come up with a list 19:24:42 SumitNaiksatam, hi 19:24:43 SridarK: i am fine with that 19:24:59 SridarK: but realistically i think its going to be one more item that we can push for 19:25:13 SumitNaiksatam: ok 19:25:15 Do we need a F2F meeting? 19:25:18 prad_: so you are tracking the fwaas requirements on the ceilometer side 19:25:28 beyounn: sure, we can 19:25:58 SumitNaiksatam, yea, we need clarity on Fwaas side what the plan is 19:26:16 SumitNaiksatam, so based on SridarK's email, Rajesh might not be able to add the hit count support? 19:26:16 prad_: i was expecting a blueprint spec on the fwaas side as well for the missing functionality 19:26:33 prad_: are you okay if that cannot be added in Juno? 19:26:42 SumitNaiksatam, i'm not familiar with fwaas side of the code to write a reasonable spec 19:26:44 prad_: if not i was going to scout for more resources on this 19:27:20 SumitNaiksatam, ideally if we can get it in for juno that would be helpful.. but if you're saying we don't have resources then I guess we have no choice but to punt? 19:27:21 i was actually going to check with badveli if he was interested in taking this up (without knowing at all as to how full your plate is) 19:27:48 badveli: this might be a good place to get your hands really dirty in fwaas 19:27:53 assuming you have time 19:27:59 Sumit: Let me and Vashul work out on time first 19:28:08 beyounn: sure 19:28:28 if not, and no one else is willing to take this up, then we cannot do hit counts in Juno 19:28:44 Sumit, how about we get the list and then we can work out the resource? 19:28:50 i would have really liked to have this since it satisfies the ceilometer requirements 19:29:03 beyounn: we already have the list 19:29:20 beyounn: #link https://wiki.openstack.org/wiki/Neutron/FWaaS/JunoPlan 19:29:36 but not all of the above will make it to the list that we send to the PTL 19:29:51 Sumit, that is what I was talking about 19:29:51 in fact my guess is that we can only have one more item in addition to flavors 19:30:00 that means that everything else is best effort 19:30:26 however, in my opinion satisfying ceilometer requriements is critical for the adoption of fwaas 19:30:27 Sumit, not even the service insertion? 19:30:33 SumitNaiksatam: and we will need to work out dependency on flavor, insertion 19:30:42 beyounn: service insertion, yes 19:30:56 beyounn: but i am thinking that as a part of the adv services work 19:31:02 SridarK: beyounn: I will work with you guys on service insertion framework migration 19:31:05 beyounn: so i am not counting that here, its cross list there 19:31:16 s3wong: awesome, thanks 19:31:25 s3wong: dont leave me out :-P 19:31:34 s3wong: knight in shining armor ;-) 19:31:42 SridarK: lol 19:31:54 Sumit, since we have the service group BP and Code out there already, I think it could be a shorter path 19:31:56 guarding the alamo! :-P 19:31:57 SridarK: beyounn: SumitNaiksatam: in fact, FWaaS will be the first one we will do - since LBaaS new object model will be around J-2 19:32:02 while he is in a lbaas mtg :-) 19:32:55 beyounn: sure, lets discuss as you guys suggested 19:33:12 #action beyounn badveli to decide if they can look at hit counts 19:33:35 in general we need to develop some expertize in the team on the iptables driver side 19:33:38 Sumit: also, if we can get the service group cleaned up, we may be able to get new resource on the next thing 19:33:42 to complement Rajesh 19:34:10 Rajesh said he could be available a bit later on - timing now is critical 19:34:17 hence i was looking for volunteers (and suggested badveli’s name) 19:34:30 SridarK: yeah, juno 2 is critical 19:34:37 SumitNaiksatam: yes agreed 19:35:11 garyduan beyounn: are you guys comfortable with the iptables driver? 19:35:37 we need someone whenever Rajesh does not have time to look at it 19:35:58 lets take this offline 19:36:10 Does everyone available next week? 19:36:16 my question is for everyone in the team in fact 19:36:19 beyounn: i am 19:36:30 yes me too 19:36:42 #action SumitNaiksatam to start email thread for meeting 19:36:43 yes 19:36:55 How about we do a F2F next week to close it? 19:36:57 but next week is too late 19:37:04 Friday? 19:37:09 we need to send list to PTL at the earliest 19:37:18 friday afternoon is good 19:37:27 ok lets decide offline 19:37:31 we are over time 19:37:32 ok 19:37:41 ok 19:37:53 prad_: the first step for getting the hit counts is to have the bp spec 19:38:03 prad_: if we cant find a resource to do that, we are stuch 19:38:06 *stuck 19:38:18 SumitNaiksatam, hmm understand 19:38:24 i could have, but i cannot commit, so i dont want to put my hand up 19:38:44 prad_: can you at least make some progress with what is already there? 19:38:52 SumitNaiksatam, my plate is a bit too full for juno2, otherwise i would have volunteered 19:38:55 prad_: otherwise we have a serious issue 19:39:02 prad_: totally understand 19:39:28 prad_: other than hit counts u can do lifecyle metrics ? 19:39:30 the fwaas team would really like to see the ceilometer integration, so thanks prad_ for taking this up 19:39:32 SumitNaiksatam, yea i already started looking into fw/rules and policy tracking 19:39:40 prad_: ok cool 19:39:51 SridarK: yes, thats what i meant to ask 19:40:03 SumitNaiksatam: ok cool 19:40:04 prad_: we can try and help you at least with that 19:40:20 cool 19:40:25 prad_: another way of saying, please bug SridarK :-P 19:40:35 prad_: we can discuss for sure no worries :-) 19:40:49 i wont put that as an action item 19:40:58 hehe ok 19:41:04 * SumitNaiksatam hides for cover before SridarK comes after me 19:41:16 #topic open discussion 19:41:18 SumitNaiksatam: SridarK would never do that :-) 19:41:26 SridarK: i know 19:41:29 :-) 19:41:38 did we miss anything important 19:41:44 i know we did not cover vendor BPs 19:41:55 beyounn: did you say you added one too? 19:42:07 SumitNaiksatam: we can discuss offline on our stuff 19:42:13 Sumit: no , i did not 19:42:15 SridarK: ok 19:42:29 beyounn: ah ok, sorry got confused with some other comment 19:42:32 ok what else? 19:42:53 Sumit: I will leave the icmp part of you comment as under discussion 19:43:01 beyounn: ok 19:43:20 i have an action item to respond to the email thread in general 19:43:35 Ok, I will follow up with you then 19:43:55 alright thanks everyone for your patience and participation 19:44:02 apologies again for starting late 19:44:10 thanks for sticking around longer 19:44:13 thanks 19:44:21 #endmeeting