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