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