18:31:17 <sc68cal> #startmeeting networking_fwaas
18:31:18 <openstack> Meeting started Wed Sep 23 18:31:17 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:31:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:31:21 <openstack> The meeting name has been set to 'networking_fwaas'
18:31:26 <sc68cal> #chair SridarK xgerman
18:31:26 <openstack> Current chairs: SridarK sc68cal xgerman
18:32:00 <sc68cal> #link https://wiki.openstack.org/wiki/Meetings/FWaaS Meeting agenda
18:32:20 <sc68cal> #info No action items from the previous meeting
18:32:25 <njohnston> o/
18:32:30 <sc68cal> #topic Bugs
18:32:51 <sc68cal> Have a new handy link for the bug tracking URL, for the meeting
18:33:16 <sc68cal> #link https://goo.gl/5h3elO FwaaS Bugs
18:34:16 <sc68cal> Looks like there has been some activity on a couple bugs mentioned last week
18:34:17 <sc68cal> https://bugs.launchpad.net/neutron/+bug/1496244
18:34:19 <openstack> Launchpad bug 1496244 in neutron "rule change via GUI/CLI puts FW in ERROR mode" [Undecided,New]
18:34:36 <sc68cal> last comment from someone indicates reproduction of the bug
18:35:09 <sc68cal> that one sounds pretty serious, is anyone investigating?
18:35:16 <SridarK> sc68cal: this could be that we may just need latest code
18:35:37 <SridarK> i think there was a fix and also a backport to kilo
18:36:29 <xgerman> can we reference that in the LP?
18:36:36 <sc68cal> ^ +1
18:36:56 <SridarK> the earlier comment on the bug indicates that they could not see it
18:36:56 <sc68cal> if we can, find the fix and backport and link 1496244 as a duplicate
18:37:05 <SridarK> but needs evaluation for sure
18:37:22 <SridarK> let me take the action
18:37:41 <sc68cal> #action SridarK follow up on https://bugs.launchpad.net/neutron/+bug/1496244
18:37:42 <openstack> Launchpad bug 1496244 in neutron "rule change via GUI/CLI puts FW in ERROR mode" [Undecided,New]
18:38:06 <sc68cal> https://bugs.launchpad.net/neutron/+bug/1496239 was fixed recently, so that's easy :)
18:38:06 <openstack> Launchpad bug 1496239 in neutron "neutron-fwaas check_migartion fails" [High,Fix committed] - Assigned to Akihiro Motoki (amotoki)
18:38:15 <sc68cal> props to amotoki!
18:38:21 <SridarK> +1
18:38:54 <sc68cal> SridarK: looks like you're already assigned to https://bugs.launchpad.net/neutron/+bug/1492142 and that one looks hairy, so IMO steady as she goes on that
18:38:55 <openstack> Launchpad bug 1492142 in neutron "FWaaS: FIP namespace created after/before Firewall creation doesn't contain FW rules" [Undecided,Confirmed] - Assigned to Sridar Kandaswamy (skandasw)
18:39:06 <sc68cal> SridarK: unless you have anything to share
18:39:28 <SridarK> sc68cal: yes i think i know the issue
18:39:54 <SridarK> with the refactor on l3 agent - i think we are missing a kick to fw in the fip ns setup
18:40:17 <SridarK> i am a bit consumed on the day job - i have not been able to confirm the fix
18:40:50 <SridarK> but in general in this regard, we should really move to the observer hierarchy that l3 agent folks have moved to
18:41:23 <SridarK> earlier since we did not have a way of listening to notifications, we had to add code in l3agent
18:41:33 <sc68cal> SridarK: ack. If you can put a comment to that effect, that sounds good to me. I think that's a good place to start
18:41:42 <SridarK> i owe bharathm an explanation also on this
18:41:46 <SridarK> sc68cal: will do
18:42:21 <sc68cal> Sort of on a similar note - at the QA sprint there was some discussion about circular dependencies and the fwaas-l3agent interaction came up.
18:42:22 <badveli> sridark: we still have that code in edge router and local router
18:42:29 <badveli> for snat name and IR
18:42:35 <bharathm> SridarK: I couldn't get enough time to look into that bug either.. But I can now..
18:42:40 <sc68cal> #link https://review.openstack.org/223343 Decoupling L3 agent and fwaas code
18:42:51 <SridarK> badveli: yes u are correct but it is not there for fip
18:43:04 <badveli> are you adding the same to Fip name space or moving to observer
18:43:52 <SridarK> sc68cal: yes this clean up is needed
18:44:02 <SridarK> now that l3 agent has been refactored
18:44:33 <SridarK> sc68cal: will add this to our list of things for M
18:44:50 <sc68cal> SridarK: yeah I haven't looked at the patch to see if carl_baldwin linked it to a bug
18:45:19 <SridarK> badveli: it seems it is best to move to observer hierarcy as pc_m has done for vpn
18:45:42 <xgerman> +1
18:45:46 <badveli> yes we had this pending, thanks
18:45:49 <sc68cal> If nobody objects, I'll make a rfe bug to track this and poke carl_baldwin to get him to his patch to it
18:45:56 <sc68cal> unless one already exists
18:46:18 * carl_baldwin just got poked.
18:46:22 <sc68cal> s/to get him to/to get him to link his/
18:46:26 <carl_baldwin> No, one doesn’t exist.
18:46:38 <SridarK> sc68cal: we may need to clean up our end as well before carl_baldwin pulls the plug on us :-)
18:47:03 <sc68cal> SridarK: agree - this one is going to take some work
18:47:46 <sc68cal> #action sc68cal create RFE bug in LP to track L3 agent decoupling
18:48:26 <sc68cal> Any other bugs? or onward to BP tracking?
18:48:48 <SridarK> sc68cal: there was an horizon issue but i think this was fixed
18:48:58 <SridarK> atleast according to the notes on the bug
18:49:05 <sc68cal> https://bugs.launchpad.net/horizon/+bug/1491637 ?
18:49:06 <openstack> Launchpad bug 1491637 in OpenStack Dashboard (Horizon) "Error when adding a new Firewall Rule" [Undecided,Fix committed] - Assigned to Rob Cresswell (robcresswell)
18:49:25 <SridarK> yes thats the one
18:49:26 <sc68cal> I think that one mentioned horizon and a recent commit fixing
18:49:49 <SridarK> i could not verify that things are working but according to Rob we should be good
18:50:16 <SridarK> vishwanathj: can i req u to do a quick check pls
18:51:25 <vishwanathj> SridarK, is your request that I attempt to reproduce the issue with the latest devstack?
18:51:42 <SridarK> vishwanathj: yes if u can and if there is an issue u can do a quick triage
18:52:03 <SridarK> vishwanathj: hence the req to u in case we need a quick triage
18:52:53 <vishwanathj> SridarK, sure, I can attempt to repro with the reference firewall implementation......but it will have to by end of day tomorrow or sooner
18:53:03 <SridarK> vishwanathj: that should be fine
18:53:03 <sc68cal> #action vishwanathj try to reproduce https://bugs.launchpad.net/horizon/+bug/1491637 in devstack
18:53:04 <openstack> Launchpad bug 1491637 in OpenStack Dashboard (Horizon) "Error when adding a new Firewall Rule" [Undecided,Fix committed] - Assigned to Rob Cresswell (robcresswell)
18:53:16 <sc68cal> vishwanathj: no rush, just report back by next week ;)
18:53:38 <vishwanathj> sc68cal, thanks for the extra time, I will need that....
18:53:51 <vishwanathj> I will share my update on the neutron-fwaas channel
18:53:59 <sc68cal> vishwanathj: no worries, and if you get stuck ping me since I have a devstack lab too and can assist
18:54:29 <sc68cal> anything else, or BP topic?
18:54:49 <SridarK> sc68cal: nothing else from me
18:55:09 <sc68cal> #topic Blueprint Tracking
18:56:09 <sc68cal> So, I think we need to work on a project plan for mitaka, just to collect all the things going on, in one place
18:56:31 <sc68cal> while also linking back to the stuff we've done to collect user stories, and the use cases we did at the SEA sprint
18:56:54 <xgerman> +1
18:57:04 <davidlenwell> +1
18:57:27 <xgerman> I sugested we meet Monday before the Tokyo summit to hash things out
18:57:32 <SridarK> +1
18:57:44 <davidlenwell> New development and addressing the things in seattle are what peak my interest the most here.
18:57:45 <xgerman> since the summit starts Tuesday'
18:58:16 <Swami> SridarK: is it going to be a personnel meeting or IRC
18:58:27 <davidlenwell> would think f2f right?
18:58:33 <SridarK> Swami: at tokyo in person
18:58:33 <xgerman> yep
18:58:42 <Swami> ok, good.
18:58:59 <badveli> is there anyway we can have a go to meeting
18:59:02 <sc68cal> I think Monday is a good idea - but let's try and do as much as possible offline before, just so we can spend high bandwidth f2f time wisely
18:59:10 <xgerman> +1
18:59:11 <badveli> so that remote people can attend
18:59:13 <SridarK> sc68cal: +1
18:59:14 <sc68cal> which also allows remote participation
18:59:19 <xgerman> yep
18:59:37 <davidlenwell> +1
18:59:47 <jwarendt> +1
19:00:06 <sc68cal> So, just spitballing, maybe we gather up everything that we're working on, in a wiki page or etherpad (don't care which)
19:00:16 <sc68cal> just so we make sure nobody is left out in the cold.
19:00:21 <xgerman> +1
19:00:25 <davidlenwell> agreed
19:00:31 <sc68cal> one may already exist, I just don't remember
19:00:36 <SridarK> #link https://etherpad.openstack.org/p/neutron-fwaas-roadmap-mitaka-summit
19:00:42 <xgerman> well, we have the trello
19:00:53 <SridarK> and yes on trello as well
19:01:02 <sc68cal> cool - that etherpad link is a good start
19:01:18 <davidlenwell> trello is good for keeping the issues orginized .. but etherpad is a better sounding board
19:02:05 <sc68cal> davidlenwell: agree. I'm going to sit and think a bit about how to carry over what we did on the trello board
19:02:44 <sc68cal> i'll try and synthesize something before Tokyo from the trello board, and that etherpad - but basically just make sure if you have work you need/want to do, put it on the etherpad
19:03:03 <mickeys> I took a pass at a first cut for the enhanced FWaaS API incorporating security groups functionality, and put it on the API evolution etherpad: https://etherpad.openstack.org/p/fwaas-api-evolution-spec
19:03:20 <sc68cal> mickeys: excellent!
19:03:25 <mickeys> I have not yet tried to correlate to the Trello use cases, but it seems like that would be a good thing to do
19:03:58 <SridarK> mickeys: +1 u have hit the essential points
19:04:00 <mickeys> I hope this can generate some discussion on the etherpad. There is lots to talk about.
19:04:33 <xgerman> +!
19:04:35 <xgerman> +1
19:04:47 <sc68cal> +1
19:04:58 <davidlenwell> +! should be a new thing that means +1 but im really excited ;)
19:05:05 <SridarK> :-)
19:06:04 <sc68cal> OK - looks like we've got a good starting point for collecting things, so we'll iterate on that etherpad. It looks pretty good imo
19:06:16 <sc68cal> the roadmap one, specifically
19:06:54 <xgerman> agreed — I was about to start something like that. Thanks mickeys!!
19:07:18 <SridarK> sounds good and we can make sure the more specific etherpads are linked to the roadmap
19:07:32 <sc68cal> ++
19:07:44 <davidlenwell> sounds good
19:08:22 <sc68cal> I just remembered one that I've failed to add - vendor decomposition. In SEA dougwig mentioned this, so I've added it to the roadmap
19:08:26 <sc68cal> nobody panic :)
19:09:06 <sc68cal> unless there is anything else we can move to open discussion
19:09:47 <sc68cal> #topic open discussion
19:09:59 <xgerman> M development is open: #link https://review.openstack.org/#/c/226906/
19:10:27 <sc68cal> woo!
19:10:32 <davidlenwell> Akanda has asked me to make fwass more of a focus week to week.. So .. sorry in advance.. but ya'll are stuck with me ;)
19:11:03 <SridarK> davidlenwell: welcome to the party and pls bring some usecases with u :-)
19:11:13 <xgerman> beer?
19:11:22 <njohnston> I have filed an RFE for enhancing security groups to filter on DSCP tags, not sure if/how that affects your FWaaS API Evolution.  I am working on the spec now.   https://bugs.launchpad.net/neutron/+bug/1498957
19:11:23 <openstack> Launchpad bug 1498957 in neutron "Add a 'dscp' field to security group rules to screen ingress traffic by dscp tag as well as IP address" [Undecided,New] - Assigned to Nate Johnston (nate-johnston)
19:11:23 <davidlenwell> mm beer
19:11:23 <xgerman> every newcomer has to buy a round...
19:11:32 <davidlenwell> xgerman: done
19:12:29 <SridarK> sc68cal: the dscp field is a trip down memory lane :-)
19:12:45 <sc68cal> SridarK: :)
19:13:02 <sc68cal> njohnston: consult the following BP - https://blueprints.launchpad.net/neutron/+spec/security-groups-dscp-filter
19:13:46 <sc68cal> njohnston: also, I don't think changing the security group API to accomodate arbitrary packet fields is feasible. Fits better in a Firewall as a Service API
19:15:33 <njohnston> sc68cal: Thanks!  I'll take a look at those.
19:18:37 <xgerman> sc68cal guess we are done?
19:18:38 <sc68cal> njohnston: good luck. SridarK and I can tell you allllllll the history behind that stuff
19:18:53 <sc68cal> njohnston: SridarK: I'll buy drinks :)
19:19:02 <SridarK> :-)
19:19:03 <sc68cal> xgerman: suppose so
19:19:24 <sc68cal> ok everyone - until next week. Tokyo approaches! Very excited to see everyone soon
19:19:29 <xgerman> +!
19:19:31 <davidlenwell> +1
19:19:36 <SridarK> ok bye all
19:19:37 <sc68cal> remember, APAC friendly one is next week
19:19:39 <hoangcx> +1
19:19:40 <vichoward> later
19:19:45 <mickeys> bye
19:19:46 <davidlenwell> lol @ xgerman
19:19:49 <sc68cal> #endmeeting