00:01:01 #startmeeting networking_fwaas 00:01:02 Meeting started Thu Oct 1 00:01:01 2015 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:05 The meeting name has been set to 'networking_fwaas' 00:01:08 #chair SridarK xgerman 00:01:08 Current chairs: SridarK sc68cal xgerman 00:01:30 o/ 00:01:33 #link https://wiki.openstack.org/wiki/Meetings/FWaaS Agenda 00:01:37 Hi SridarK and all 00:01:47 Hi sc68cal :-) 00:01:57 #topic recap action items from last meeting 00:02:22 #link http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-01-07-18.30.html Action items 00:02:34 #undo 00:02:35 Removing item from minutes: 00:02:48 #link http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-09-23-18.31.html Action items 00:03:09 SridarK: how goes https://bugs.launchpad.net/neutron/+bug/1496244 ? 00:03:09 Launchpad bug 1496244 in neutron "rule change via GUI/CLI puts FW in ERROR mode" [Undecided,New] 00:03:41 sc68cal: ok looks like the submitter is in a older version of stable/kilo 00:04:19 he needs to get on the next release which i think should happen soon as the fix in only early Sep 00:04:28 i have updated the bug with details 00:04:46 SridarK: ok. I'll keep an action item for next week to wait for reporter to respond 00:04:58 once he clarifies we can Dup the bug 00:05:10 to the original fix 00:05:16 sounds good sc68cal 00:05:27 +1 00:06:05 #action SridarK see if original reporter responds to https://bugs.launchpad.net/neutron/+bug/1496244 00:06:05 Launchpad bug 1496244 in neutron "rule change via GUI/CLI puts FW in ERROR mode" [Undecided,New] 00:06:37 As for me - I made the bug to track L3 agent decoupling at https://launchpad.net/bugs/1500960 00:06:37 Launchpad bug 1500960 in neutron "Decouple FwaaS from L3 Agent" [Undecided,New] 00:06:58 sc68cal: +1 we can track using that 00:07:15 vishwanathj: Thanks for trying to reproduce https://bugs.launchpad.net/horizon/+bug/1491637 in your devstack 00:07:15 Launchpad bug 1491637 in OpenStack Dashboard (Horizon) "Error when adding a new Firewall Rule" [Undecided,Fix released] - Assigned to Rob Cresswell (robcresswell) 00:08:04 o/ 00:08:33 #topic bugs 00:08:45 xgerman: you added a bug to the agenda, want to discuss? 00:08:50 sure 00:08:56 it seems we don’t enforce quotas 00:09:35 and I found that old bug which had a fix and then didn’t and wanted to see if we agree if it’s minor and if we actually want quotas... 00:10:04 #link https://bugs.launchpad.net/neutron/+bug/1399280 Quota bug 00:10:04 Launchpad bug 1399280 in neutron "FWaaS extension doesn't register its quota resources" [Low,In progress] - Assigned to Ralf Haferkamp (rhafer) 00:10:30 1) do we want quotas? 00:11:09 I think it's reasonable 00:11:41 well, then we should raise the level to Major ;-) 00:12:11 My main concern is that without quotas we'd fill up a physical device with rules, create DOS situations 00:12:30 yeah, same here 00:13:07 hopefully we can get armax to bump https://bugs.launchpad.net/neutron/+bug/1399280 to a higher importance. xgerman suggests Major 00:13:07 Launchpad bug 1399280 in neutron "FWaaS extension doesn't register its quota resources" [Low,In progress] 00:13:23 * armax looks 00:13:31 hail the new PTL 00:13:38 don't know if it's PTL only that can assign priority. Basically I can't. :( 00:13:38 * xgerman bows 00:13:45 so when in doubt, go crying to armax 00:13:48 yeah, I can’t neither 00:13:51 :-) 00:13:57 sc68cal: I can fix that 00:14:01 if you want the privilege 00:14:08 NICE 00:14:16 xgerman: you too? 00:14:21 ++ 00:14:26 sure - I love power 00:14:32 with privelege come responsibility ;-) 00:14:43 kidding 00:14:45 SridarK: that’s riiiiight!!! 00:15:09 i can see armax volunteering somebody for a bug scrub ;-) 00:15:27 * sc68cal already has it on his list for things that need to be done 00:15:42 sc68cal, xgerman your LP handle? 00:15:45 well, we will each grab a cheesesteak and get on it 00:15:54 :) 00:16:01 armax: scollins 00:16:03 german-eichberger 00:16:09 * sc68cal needs to fix that 00:16:18 sc68cal: see if you can bump up the priority 00:16:31 xgerman: ditto 00:16:45 armax: ACK. worked 00:16:52 sc68cal: sweet 00:16:52 same here — awesome!! 00:16:56 see? crying helps :) 00:17:01 :) 00:17:13 we will see how it looks like at the end of your tenure ;-) 00:17:14 I can come and cry to you too though, right? 00:17:17 :-) 00:17:22 armax: course :) 00:17:26 nice 00:17:27 armax absolutely 00:17:38 ok 00:18:42 anyway I also changed the state back to triaged, and cleared the assignee 00:18:51 since it's been 9 months since it's had activity 00:18:53 oh, not aware that the alternate neutron-fwaas meeting was at this time 00:20:06 xgerman: is the next step to track down the abandoned patch set, and see if it can be resurrected? 00:20:13 sc68cal: +1, so xgerman: the target is for M ? 00:20:24 yeah, maybe backports 00:20:27 xgerman: and we can backport 00:20:34 yep 00:21:11 xgerman: mind if I set that as an action item for you, for next week? 00:21:26 yep, I will look into it 00:21:51 #action xgerman investigate https://review.openstack.org/139124 and report back 00:22:51 I guess one I can bring to the table is https://bugs.launchpad.net/neutron/+bug/1497066 00:22:51 Launchpad bug 1497066 in neutron "If IP version is not specified while creating Firewall Rule, then it should populate it based on the Source and Destination IP" [Undecided,In progress] - Assigned to Reedip (reedip-banerjee) 00:23:16 Yes, I wanted to discuss this as well 00:23:19 :) 00:23:51 #link https://review.openstack.org/#/c/228369/ discussion of fix for 1497066 00:24:28 The issue is right now fwaas doesn't validate ip_version and src and destination, to ensure they both match ip_version 00:24:49 my thought is, that's an API validation problem and we should report an error back to the user 00:25:39 hence, marking the bug as a dup of https://bugs.launchpad.net/bugs/1487599 00:25:39 Launchpad bug 1487599 in neutron "fwaas - ip_version and IP address conflicts are not raised" [Undecided,In progress] - Assigned to Sean M. Collins (scollins) 00:26:09 yeah, we should send feedback 00:26:11 I agree with sc68cal, but on the point that if the user provides an ip_version and source/destination IP version do not match the IP version provided by user, then we should report an error 00:26:25 BUT if we want to redesign the API does it make sense to fix bugs in the old one 00:26:44 xgerman:+1 00:26:50 if the user does not provide an ip_version argument, then it should be populated based on the source/destination IP 00:26:54 reedip: this does seem a minor variation of 1487599 00:27:10 SridarK : I think both the issues make a single bug 00:27:40 they are part of a single bug related to the ip_version, and not exact duplicates. 00:27:43 reedip: can we not have this covered in the earlier patch ? 00:28:23 SridarK: After verifying the patch and yesterday's discussion with sc68cal, I agree with your point 00:28:53 ok makes sense as it is an api validation as sc68cal: points out 00:28:59 I think probably reedip has highlighted something about the neutron APIs - that really is ip_version required as an attribute 00:29:24 when we have src and destination, and can infer the ip_version based on the addresses (barring any corner cases) 00:30:34 sc68cal: agree, we may have a scenario to say we are v4 but src and dst are not specified (any, any) 00:30:41 SridarK: But during my discussion with sc68cal, what I was not able to understand was the importance of ip_version for the user. 00:31:08 SridarK: ah. yep. that's a good point. 00:31:27 reedip: something like "Block all v4 traffic to port 80" 00:32:19 isn’t that more like black any ipv4 address from getting to this port? 00:32:20 SridarK: Means ip_version and source/destination IP can be mutually exclusive? 00:32:53 so I am not sure if that is explicitly needed if we can model a wildcard for all ipv4 addresses 00:32:57 I mean if IP_version is v4 and port is 80, means block all traffic to port 80 00:33:30 reedip: problem is if we have a rule that is src= any and dst = any, we can't figure out the ip_version 00:33:32 reedip: xgerman: yes that could be an intended objective 00:34:00 although we could construe "any" to mean both ipv4 and ipv6 addresses 00:34:05 reedip: well i think all that means is that it will go to v4 iptables 00:34:06 sc68cal : but then it means you want to block ALL traffic, right? 00:34:15 reedip: no, it could be an ALLOW rule. 00:34:23 ore REJECT 00:34:31 but then we're now making implicit behaviors rather than explicit. 00:34:48 people would have to now know, that when they say "ANY" - that now means ipv4 and ipv6 both 00:35:05 yeah, that might get confusing 00:35:26 seems like we may be stuck with ip_version. 00:35:28 sc68cal : Exactly. if src and dest address is not specified, it means the Firewall rule should operate on all IPv4 and IPv6 addresses 00:35:34 sc68cal: yes 00:35:49 reedip or we have an error 00:36:16 I am still in the camp to make the user use wildcards in the ip field for that 00:36:18 reedip: then how do we specify a rule for only v4 traffic 00:36:36 specify ip_version as 4 specifically 00:36:45 SridarK: instead of a default 4 value 00:37:08 anyway, I want to try and timebox this discussion. I think we can probably take this to the ML for further discussion. I don't want my bikeshed to take up time, I know the APAC people like hoangcx have been very patient :) 00:37:10 reedip: ok i see ur point - on the default 00:37:32 but we should keep thinking about this, it's a knotty issue 00:37:48 sc68cal: agree, reedip: lets discuss on the bug 00:37:49 sc68cal , SridarK, :I agree, we can take it up again in the mailing list 00:38:07 reedip: or on the bug in LP itself 00:38:25 sridark: on LP would be better 00:38:39 ok lets move on 00:38:41 otherwise I think this issue will take a long time for others 00:38:57 and I was just getting my brush... 00:39:01 any other bugs that we want to discuss? I want to try and breeeze through bps so we can get to open discussion 00:39:05 xgerman: :) 00:39:13 :-) 00:39:32 #topic blueprints 00:40:19 I dropped the ball by not making a action item for myself for actually combining the trello and our etherpad 00:40:50 So, in the meantime, make sure you have your stuff added to the etherpad 00:41:01 ok 00:41:17 #link https://etherpad.openstack.org/p/neutron-fwaas-roadmap-mitaka-summit Mitaka roadmap 00:41:17 #action sc68cal combine troll with etherpad 00:41:25 xgerman: :) 00:41:27 badveli: i think u want to move on service group 00:41:40 xgerman: feels the power today ;-) 00:41:40 yes 00:42:03 its already in ether pad 00:42:58 Sridark we had a blue print for E-West case should we revive that 00:43:36 badveli: we should combine that with mickeys: etherpad 00:43:47 +1 00:43:49 Don't we have to converge on how we want to solve east/west before submitting a blueprint? 00:43:53 +1 00:43:56 RFE: Sure we can go ahead 00:44:04 ok thanks 00:44:22 yeah I just updated the etherpad to make a new 2.1 point for solving east west api semantics 00:45:44 I think we kind of know what we need to do, I guess we just need face 2 face time at summit to hash out how to 00:46:14 I don't know if the DVR team will be willing to make major changes. If not, it is not obvious to me which way to go. 00:46:26 on this note, mickeys: , badveli: Swami may be in the bay area next week - if we want to get some f2f for discussions 00:46:47 I am probably out on Monday and Tuesday, should be OK the rest of the week 00:47:02 will keep u posted, if we can do a discussion we can summarize for remote folks 00:47:12 SridarK: awesome 00:47:32 based on the discussions at the QA summit, DVR needs some care and feeding on many fronts 00:48:17 DVR needs to work with advanced services, and also be stable. So, I think as long as we are constructive and willing to help with the DVR code we should be OK 00:48:53 going to quickly move to open discussion and let others talk 00:48:57 #topic open discussion 00:49:25 hoangcx: good morning! have anything you want to talk about? 00:49:55 sc68cal: Yeah. Logging API need to get more comments from you and all of us 00:50:25 sc68cal: especially in design for proposing API. 00:50:56 sc68cal: source code is still in progress and will upload for current design soon (maybe early next week) 00:53:32 sc68cal: That's all from me. 00:53:59 hoangcx: cool. I know regXboi and i have been reviewing when we have capacity 00:54:11 I appreicate your patience 00:55:20 sc68cal regXboi: thank you all. :-) 00:55:48 Just wondering if there is any feedback on the API proposal 00:56:02 mickeys: which? 00:56:08 the ether pad one 00:56:12 That I put in the API evolution etherpad 00:56:32 #link https://etherpad.openstack.org/p/fwaas-api-evolution-spec 00:56:37 it’s a really good first step but I think we need to go further given all the stuff the community expects (see troll) FWaaS to do 00:56:55 mickeys: WIP for me, juggling on multiple things 00:57:21 mickeys: ah, I haven't looked at it yet 00:57:30 mickeys: I'll review tomorrow 00:57:51 sc68cal: I will check for comments tomorrow. Thanks. 00:58:04 #action sc68cal review proposed API changes in https://etherpad.openstack.org/p/fwaas-api-evolution-spec 00:58:10 there. that'll keep me honest 00:58:11 mickeys can you turn it into a spec so we can comment a bit better 00:58:27 just throwing that out 00:58:46 xgerman: You mean submit a blueprint? 00:59:24 that, too 00:59:34 I was more thinking a rest file descrying the proposed API 00:59:42 rst 00:59:52 time check 00:59:55 yep 01:00:07 yeah, let’s pick that up next week 01:00:13 in the meantime ether pad ;-) 01:00:20 xgerman: +1 01:00:22 See everyone next week! 01:00:26 #endmeeting