18:32:35 <sc68cal> #startmeeting networking_fwaas
18:32:36 <openstack> Meeting started Wed Oct  7 18:32:35 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:32:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:32:39 <openstack> The meeting name has been set to 'networking_fwaas'
18:32:58 <sc68cal> #topic recap last meeting actions
18:33:00 <hoangcx> Hi
18:33:34 <sc68cal> #link http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-10-01-00.01.html Previous meeting minutes
18:34:00 <sc68cal> SridarK: I set 139124 as invalid since the reporter hasn't come back
18:34:15 <SridarK> sc68cal: yes sounds good
18:34:25 <sc68cal> SridarK: so that sets a clock on the bug before it gets closed
18:34:47 <SridarK> sc68cal: makes sense, i think this should go away
18:34:57 <sc68cal> yep, worst case it'll automatically in 60 days
18:35:08 <davidlenwell> o/
18:36:09 <sc68cal> xgerman: how did your investigation go
18:36:18 <xgerman> I made a fix
18:36:42 <xgerman> #link https://review.openstack.org/#/c/231246/
18:36:59 <sc68cal> SridarK: sorry, I meant 1496244 in my previous lines
18:37:11 <xgerman> that will enable quotas + I have the unit tests to proof it ;-)
18:37:21 <SridarK> sc68cal: oh yes got it no worries
18:37:57 <sc68cal> xgerman: awesome. I'll make sure to review before next meeting
18:38:05 <lalitd> bauzas: r u there?
18:38:24 <bauzas> lalitd: please move to -noba
18:38:28 <sc68cal> As for me, I compared the trello board and the etherpad
18:39:02 <sc68cal> The items we have in the etherpad corresponded to items we had in the trello board, so we aren't missing anything, with the exception of DVR and FwaaS compatability
18:39:14 <sc68cal> so I added a trello card for it, just to sync the two
18:40:00 <sc68cal> mickeys: I did review the API chances in the other etherpad, I have some concerns that I'll figure out a better time to go over
18:40:05 <sc68cal> probably the ML
18:40:13 <mickeys> sc68cal: ok
18:40:47 <sc68cal> #info Agenda https://wiki.openstack.org/wiki/Meetings/FWaaS
18:40:50 <sc68cal> #topic bugs
18:41:32 <sc68cal> fresh one here - https://bugs.launchpad.net/neutron/+bug/1503642
18:41:32 <openstack> Launchpad bug 1503642 in neutron "Firewall-Update command help content does not display "admin_state_up" argument" [Undecided,New] - Assigned to James Arendt (james-arendt-7)
18:42:12 <xgerman> jwarendt anything you want to add?
18:42:41 <jwarendt> Yes, the call lobs any parameter across.  The ones that work - name, description, admin_state, shared
18:43:09 <jwarendt> Ones that aren't recognized ex: --foo-bar hit the server and rejected as unrecognized attributes
18:43:39 <jwarendt> Ones with 'allow_put = False' rejected as read-only.
18:43:55 <Swami> hi
18:44:16 <jwarendt> This means none of those are documented in the default help settings for the python-cli.  So question is whether to add them all?
18:45:16 <sc68cal> So this bug looks more like an opinion
18:45:24 <jwarendt> I.e. can update the name or the description, not just admin_state_up, and also not documented.
18:46:19 <jwarendt> I can add explicit parser parameters with help for all of the valid at the REST boundary values, if that has value.
18:46:47 <sc68cal> jwarendt: I think that has value
18:46:54 <xgerman> help is  a good function to have given the state of the docs
18:46:57 <xgerman> sc68cal +1
18:47:11 <SridarK> jwarendt: yes if the server can understand it - it is picked up
18:47:50 <SridarK> but adding this has value for sure
18:48:30 <jwarendt> Ok - will add explicit values across the board.
18:49:10 <SridarK> jwarendt: +1
18:49:58 <xgerman> +1
18:50:05 <sc68cal> jwarendt: thanks :)
18:50:38 <sc68cal> Which bharath reported https://bugs.launchpad.net/neutron/+bug/1501597 ?
18:50:38 <openstack> Launchpad bug 1501597 in neutron "Adding Brocade Vyatta 5600 support in Neutron-Fwaas" [Undecided,In progress] - Assigned to bharath (bharath-7)
18:51:42 <bharathm> Not me
18:51:53 <SridarK> :-)
18:52:06 <xgerman> yeah, bharath-7 - so we know there are 5 more
18:52:08 <sc68cal> Basically, I understand that brocade wants to add support for their driver, but during the Mitaka release I really want to push the drivers into their own repos, similar to the vendor decomp that was done in neutron main tree
18:53:02 <SridarK> sc68cal: +1 this is the thought process on our vendor stuff as well
18:53:54 <sc68cal> So, I just want to try and give everone the heads up that we should be moving in that direction
18:53:59 <xgerman> but wouldn’t that be independent from the bug system which repo they land
18:54:24 <xgerman> so they could still file bugs/RfE in FWaaS but the code would land in their own repo
18:54:29 <sc68cal> xgerman: correct. I think it's just that the patches to add support for their newer image, got me thinking about trying to get them to decomp
18:54:57 <xgerman> cool - that’s what i thought. Just wanted to clarify...
18:55:16 <SridarK> xgerman: there probab is a widget or attribute to mark it for a specific vendor on LP as well
18:57:05 <sc68cal> anyway, any other bugs to discuss?
18:58:05 <sc68cal> #topic blueprints
18:58:24 <sc68cal> I added a link for doing a LP query for RFE bugs
18:58:47 <sc68cal> #link https://goo.gl/RZeEJp RFE bugs with "FwaaS"
18:59:51 <sc68cal> If anyone has an RFE or bug they want to discuss, here's your chance
19:00:44 <xgerman> looking at this list we really need to decide on priorities
19:01:12 <xgerman> #action xgerman take a stab at assigning priorities
19:01:40 <jwarendt> +1
19:01:46 <sc68cal> +1
19:02:00 <SridarK> +1
19:02:50 <SridarK> i think we pull more things here
19:03:11 <SridarK> i guess the new stuff is really logging and classifiers
19:03:31 <SridarK> and Brocade
19:03:46 <sc68cal> and DVR
19:03:50 <SridarK> but surely prioritization is needed
19:03:56 <SridarK> sc68cal: yes
19:04:58 <mickeys> classifiers are intertwined with the new API, from the FWaaS perspective
19:05:10 <jwarendt> +1
19:05:37 <SridarK> with some discussions during the summit - may be on Fri we take a deep breath and get a good first stab at priorities
19:05:50 <xgerman> sounds good
19:06:04 <sc68cal> yeah that sounds like a good plan
19:06:15 <xgerman> but we also should architect + figure out milestones
19:06:26 <SridarK> yes certainly
19:06:37 <sc68cal> I feel bad that a lot of things are in stasis until the summit, but I think a lot of these conversations will be easier at the summit
19:06:59 <sc68cal> just due to higher bandwidth
19:07:17 <xgerman> agreed + we should aim for a midcycle
19:07:29 <sc68cal> ++ for midcycle
19:07:42 <jwarendt> +1
19:08:14 <SridarK> +1 on midcycle
19:09:11 <xgerman> not sure if we do some L4-L7 mid cycle… or split them up
19:10:12 <SridarK> xgerman: with classifiers - will be good to combine, but we are not at that stage yet
19:10:19 <xgerman> ok
19:10:29 <SridarK> so may be it does not matter
19:11:05 <SridarK> either way will be fine, if there are some logistics that are easier
19:11:45 <xgerman> yeah, we are talking about it that afternoon in LBaaS land so we should have some proposal next week
19:12:16 <badveli> are we going to discuss the new API at summit?
19:12:32 <xgerman> sc68cal said in the ML
19:13:13 <mickeys> Start on ML, see how far we can get, then continue at the summit?
19:13:20 <sc68cal> ^ +1
19:13:21 <xgerman> +1
19:13:27 <jwarendt> +1
19:13:36 <SridarK> +1 and also on the etherpad
19:13:39 <xgerman> I also made some pretty basic component design: https://docs.google.com/a/hpe.com/drawings/d/1eFDVOtkwG2Flt54zqZcAFnOY9cww_EgJKuIp9aPqAIs/pub?w=1440&h=1080
19:13:43 <xgerman> #link https://docs.google.com/a/hpe.com/drawings/d/1eFDVOtkwG2Flt54zqZcAFnOY9cww_EgJKuIp9aPqAIs/pub?w=1440&h=1080
19:13:44 <badveli> ok thanks i will follow them
19:14:05 <xgerman> because I think we need to be more pluggable - especially with all those new things
19:14:18 <mickeys> xgerman: I don't have permission for either google doc
19:15:01 <SridarK> yes same here
19:15:02 <badveli> could we get the permissions, thanks
19:15:02 <xgerman> it should have a request access and I can approve you
19:15:22 <xgerman> https://usercontent.irccloud-cdn.com/file/xP9vfgrP/sOErZ5NSprBN3xAYgZxWtqg-2.png
19:15:30 <xgerman> let’s try that
19:15:40 <mickeys> The last one works
19:15:51 <SridarK> +1
19:15:51 <sc68cal> I like the idea of separate API endpoints and common backend
19:16:23 <sc68cal> I think the proposed API on the etherpad, it starts to mix things in at the API level
19:16:48 <mickeys> If we don't mix in at the API level, then the existing port to security group mappings are not reusable in FWaaS
19:17:15 <xgerman> well, if they use the same backend you can start in SG and then finish in FWaaS
19:17:23 <mickeys> +1
19:18:47 <xgerman> #action xgerman fix the sharing on the Google doc so everybody can edit
19:20:37 <reedip_> Thats a nice API diagram xgerman :)
19:20:40 <badveli> since the iptables manager is common we can combine as a common back end but the applicability of security group is per port hopefully we do not have if then kind of things in common backend
19:21:03 <xgerman> well, I like that all to be pluggable
19:21:20 <xgerman> so we could put in an SDN plugin in lieu of iptables
19:21:22 <sc68cal> I liked the one point on the etherpad, where maybe moving fwaas to be on a port basis rather than router basis
19:21:48 <xgerman> +1
19:21:56 <SridarK> sc68cal: yes that was the intent
19:23:05 <SridarK> sc68cal: putting it on the router was not my first choice either
19:24:13 <SridarK> sc68cal: yes that should be something that should be easy to move to - the db tables are designed to be able to make the move easy
19:24:13 <xgerman> there is some exotic use case to use FWaaS to protect other Neutron services, e.g. VPNaaS — but de-emphasizing router is good
19:24:14 <mickeys> SridarK: DVR breakage seems like a good excuse why we need port rather than router
19:24:27 <sc68cal> mickeys: +1
19:24:32 <SridarK> mickeys: yes and also that it makes more sense
19:24:33 <xgerman> +!
19:24:35 <xgerman> +1
19:24:54 <mickeys> +!
19:25:16 <SridarK> the router is a bit nebulus and we need more specificity and more in line with traditional implementations
19:25:40 <xgerman> I guess we are running in an open door
19:25:42 <SridarK> so i think we found one high priority thing
19:25:47 <xgerman> so let’s make it so ;-)
19:25:49 <sc68cal> :)
19:25:51 <SridarK> :-)
19:26:13 <xgerman> time check 5 minutes...
19:26:27 <sc68cal> #info Consensus among today's meeting that moving the FwaaS API to be port based is desirable
19:26:41 <xgerman> SridarK should we discuss the FWaaS talk in Tokyo?
19:26:55 <xgerman> any, Google Doc we can collaborate on?
19:26:55 <SridarK> xgerman: yes been on my mind
19:27:05 <SridarK> xgerman: look for an email
19:27:11 <jwarendt> Port makes sense, as long as still have grouping constructs for those of us too lazy to iterate all of a router's ports..
19:27:12 <SridarK> and we can get folks to add in
19:27:14 <xgerman> ok, awesome
19:27:28 <mickeys> jwarendt: +1
19:27:34 <SridarK> jwarendt: the initial bp called for a port list i believe
19:27:40 <sc68cal> jwarendt: +1
19:27:54 <xgerman> and then there are zones...
19:27:58 <SridarK> then there are zones
19:28:07 <SridarK> oh xgerman: u read my mind
19:28:10 <SridarK> ;-)
19:28:17 <xgerman> great minds think alike ;-)
19:28:21 <mickeys> IMO it is important to be able to use the port grouping construct (security groups?) in the rules themselves, for source or dest address
19:28:31 <mickeys> Which security groups already does
19:28:36 <SridarK> ok i will stay away from the other option on that saying :-)
19:29:07 <xgerman> 1 minute...
19:29:18 <SridarK> mickeys: yes that we should discuss for sure
19:29:33 <sc68cal> mickeys: true, but we also have an item for service grouops, so that may satisfy requirement
19:29:41 <SridarK> we should not make the api support every possibly option
19:29:42 <sc68cal> *groups even
19:30:12 <xgerman> well, we release the bare minimum and see what we learn
19:30:25 <sc68cal> and with that, we're out of time
19:30:29 <sc68cal> until next week!
19:30:34 <sc68cal> #endmeeting