18:32:54 <sc68cal> #startmeeting networking_fwaas
18:32:55 <openstack> Meeting started Wed Dec  2 18:32:54 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:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:32:58 <openstack> The meeting name has been set to 'networking_fwaas'
18:32:59 <xgerman> yeah, let’s make sure we got the right name :-)
18:33:16 <sc68cal> #chair xgerman
18:33:17 <openstack> Current chairs: sc68cal xgerman
18:33:21 <sc68cal> #chair SridarK
18:33:21 <openstack> Current chairs: SridarK sc68cal xgerman
18:33:39 <ajmiller> Hi
18:33:56 * pc_m lurking (as usual)
18:34:01 <njohnston> o/
18:34:03 <sc68cal> So, since we're still working on the API spec I figure we can probably use this time to talk, in a less latentcy setting
18:34:12 <sc68cal> *low latency
18:34:35 <sc68cal> but I know pc_m just put a big e-mail on the list about some things so he may want to chat
18:34:36 <SridarK> +1
18:34:37 <xgerman> yep, just make sure to read through the links in the announcements + we need to talk 5 minutes midcycle
18:34:53 <xgerman> #link https://wiki.openstack.org/wiki/Meetings/FWaaS#Agenda_for_Next_Meeting
18:36:06 <SridarK> i think the spec is converging, mickeys: thanks for the responses to my last set of comments
18:36:16 <xgerman> +1
18:37:43 <sc68cal> I think based on the etherpad it looks like the same week as lbaas would be useful
18:37:48 <sc68cal> less logistics to deal with
18:38:08 <sc68cal> #link https://etherpad.openstack.org/p/lbaas-mitaka-midcycle
18:38:35 <xgerman> well, we are hosting Cosmos anyway in Seattle = dougwig will be there
18:38:56 <SridarK> sc68cal: yes i agree too
18:38:57 <dougwig> Kosmos
18:39:10 <pc_m> sc68cal: talking about the constants?
18:39:55 <SridarK> xgerman:  u will need to straddle lbaas and fwaas - so are we doing complete overlap on the days ?
18:40:43 <dougwig> are you thinking co-locate, or completely separate? i think some of the lbaas folks are interested in fw stuff.
18:40:55 <xgerman> co-locate
18:41:10 <xgerman> but maybe use a different corner room for breakout
18:41:14 <dougwig> ok, good.
18:41:29 <xgerman> or we can do Seattle… then we get more HP people
18:41:36 <dougwig> sigh.
18:41:39 * dougwig smacks xgerman
18:42:18 <sc68cal> either way lets please decide - like now. Frankly we shouldn't be changing - people could be booking their travel as we speak
18:42:22 <sc68cal> hint hint...
18:42:45 <xgerman> smaks me and then quits - what is that supposed to tell me
18:43:00 <SridarK> if there is some overlap on folks - then colocate with lbass makes more sense ?
18:43:22 <vishwanathj> xgerman, looks like you smacked about hard at him :)
18:43:25 <SridarK> xgerman: u will need to clone urself or timeshare if we also overlap on all the days
18:44:29 <xgerman> true
18:45:05 <jwarendt> I'm of course partial to Seattle, being based here, so on German's side despite smackage.
18:46:16 <sc68cal> ok - so someone needs to tell me where the heck i'm booking my flight for
18:46:36 <dougw2> sc68cal: netsplit crash
18:46:38 <dougw2> what was the result?
18:46:40 <xgerman> dougw - what’s your recommendation?
18:46:52 <xgerman> dougw2 I won the smack down
18:46:57 <xgerman> bit no location yet
18:47:08 <dougw2> i'd like to see us all in texas.
18:47:40 <sc68cal> I agree with doug
18:48:14 <dougw2> nuts, eavesdrop is hosed too.
18:49:12 <mickeys> xgerman: Are you proposing a different week in Seattle, or are you planning to clone yourself?
18:49:25 <xgerman> different week in Seattle
18:49:47 <xgerman> January 12-15 in San Antonio, TX, collocated with LBaaS
18:49:47 <xgerman> January 19-22 in Seattle, WA, collocated with Kosmos (GSLB)
18:49:59 <xgerman> those are the options
18:51:33 <mickeys> I should be OK either way
18:51:46 <SridarK> I am fine with either - earlier is better - so we can get things moving. I will need to ask for approvals etc ..
18:52:24 <sc68cal> I would prefer the 12th
18:52:25 <xgerman> sc68cal/dougw2 you like San Antonio
18:52:28 <xgerman> ?
18:52:59 <SridarK> xgerman: would it work for u to have both lbaas and fwaas at the same time ?
18:53:18 <dougw2> i'll be at both, though i have kosmos marked as jan 20-22, not 19-.  i'd like to at least finalize the api in the earlier one.
18:53:18 <SridarK> if u are good then lets decide quickly and spend some time on the spec
18:53:36 <xgerman> I am good with either
18:53:57 <xgerman> I am trying to focus on FWaaS more anyway
18:54:08 <johnsom> Kosmos is 20-22
18:55:10 <SridarK> ok cool - so we have a decision then for Jan 12 ?
18:55:18 <xgerman> looks like it
18:55:36 <xgerman> hope we have good remote options for the HP people our budget doesn’t cover ;-)
18:55:50 <SridarK> xgerman: +1
18:55:52 <dougw2> can you use fw as a wedge to get some more budget?
18:56:41 <xgerman> if I only would control my budget - I would just get a rental and drive them...
18:57:14 <jwarendt> Hmm - San Diego to Seattle to San Antonio - quite a road trip.
18:57:41 <SridarK> xgerman: can u pick me up on the way somewhere :-) My boss would happy on the travel budget savings too
18:59:02 <sc68cal> alright - so unless there are any problems it looks like the 12th
18:59:13 <xgerman> yep
18:59:30 <sc68cal> only got 30 minutes so let's get into the api spec review
18:59:38 <xgerman> +1
18:59:56 <SridarK> +1
19:00:40 <mickeys> +1
19:02:26 <mickeys> I see two technical issues where we do not yet have consensus: 1) source_ip_address, source_address_group, source_firewall_group, can more than one be specified with OR semantics? Or at most one can be specified? Same issue for destination
19:02:54 <SridarK> mickeys: yes
19:03:00 <xgerman> I think at most one would be ok
19:03:35 <SridarK> also on the _firewall_group usage in rules - we are only picking the ports where the policy is bound to
19:03:56 <SridarK> and the rules contained in them are effectively a no op ?
19:04:07 <SridarK> them -> firewall_group
19:04:35 <xgerman> yep, that is my understanding as well
19:05:00 <mickeys> SridarK: For firewall_group in firewall rules, it is essentially converted into a list of addresses corresponding to all the VM ports in that firewall_group
19:05:15 <xgerman> though I can also see that we only let you use firewall_groups in that way which don’t have rules...
19:05:18 <mickeys> Same thing as remote_security_group today
19:05:57 <SridarK> mickeys: yes i see that we are trying to keep some symmetry to that model
19:06:02 <sc68cal> I have a lot of concern about how complex this is all getting
19:06:13 <jwarendt> +1
19:06:26 <SridarK> yes my concern on this part was also that
19:06:53 <sc68cal> Frankly I almost wonder if it would be worth investigating API microversioning so we start small and simple then start building more complexity later
19:07:19 <sc68cal> because frankly we're already at M-1 and we've just been baking ever more complex interactions into this API. There is no code done.
19:08:12 <sc68cal> I mean I gave in on service_groups
19:08:16 <xgerman> well, do you want us to start coding while the spec is bing negotiated?
19:08:26 <sc68cal> but now we're also going to handle firewall_groups and all these layers of indirection?
19:08:29 <SridarK> sc68cal: agree - we really want to get something code wise out
19:09:34 <sc68cal> It's like - how much more advanced things are we going to pack into the firewall_rule object
19:09:51 <mickeys> We discussed whether we need all of source_ip_address, source_address_group, and source_firewall_group. The consensus was to leave source_ip_address so that simple rules could be constructed, and to leave address group separate from (firewall) port group. This means more objects which can be perceived as more complexity.
19:11:35 <mickeys> Security groups today has some of this complexity in the form of remote_ip_prefix and remote_group_id
19:11:40 <SridarK> i am fine with ip addresses and address groups - using the _firewall_groups - i guess is to keep some alignment with Sec Groups ?
19:12:04 <SridarK> i think u answered my question
19:12:15 <mickeys> address groups is new (not in security groups), but has been mentioned in the past by several people
19:12:16 <xgerman> My preference is to close on that spec and then start coding…
19:12:32 <xgerman> did we ever decide who will do the coding?
19:13:13 <SridarK> i can definitely volunteer for some of the changes around the plugin changes
19:13:38 <sc68cal> I am on hand to help as well - probably at the REST API layer if there are no objections
19:13:48 <sc68cal> either that or the database model
19:13:56 <xgerman> I can volunteer Aish, jwarendt, and myself
19:14:04 <SridarK> ok
19:14:08 <jwarendt> +1
19:14:10 <Aish> +1
19:14:26 <mickeys> I hope to clear up internal issues in the next couple of weeks, then I can volunteer, but I will need some ramp up time
19:15:16 <badveli> sc68cal: is service groups in m-1 otherwise i can partly help with anything else
19:15:41 <xgerman> well, m-1 got cut today so I think it will be in m-2
19:15:53 <SridarK> perhaps we are getting a bit ahead of ourselves - but we need someone to look at iptables interactions on the vm port side of things
19:16:47 <mickeys> The ability to specify multiple firewall groups / policies on the same port has big implications, will lead to big changes in the reference implementation even for router ports
19:17:16 <xgerman> yep, and we need to make sure with all those people that we have proper launchpad tasks/blueprints
19:17:35 <mickeys> Depending how we resolve this, not sure if VM ports should leverage the router port implementation, the existing security group implementation, or start from scratch?
19:17:47 <SridarK> mickeys: yes true for router ports as well - ip tables linkages will need some looking into
19:17:49 <mickeys> As far as plugin and agent
19:18:10 <xgerman> ok, I think we have enough people to do the more ambitious API
19:18:32 <SridarK> xgerman: i would play this more conservatively
19:18:57 <SridarK> we can have folks look in to things but in terms what we get into M - it will be tight
19:19:11 <SridarK> even UT's take significant time
19:19:57 <SridarK> and we will have quite a bit dependencies on the base layer to get done
19:19:58 <sc68cal> changing all this stuff without breaking UTs (which are all probably brittle as hell) is going to take a lot of time
19:19:58 <mickeys> For API and DB, we probably have enough time. For reference implementation, we need to make some progress on a design before we really know what we are getting ourselves into
19:20:35 <SridarK> mickeys: we will need to have some basic reference implementation in
19:21:10 <jwarendt> +1
19:21:20 <SridarK> perhaps we can ask for an exception but an API without a backing ref implementation is frowned upon in the community
19:21:30 <mickeys> SridarK: Agreed. I think the basic structure of firewall groups, allowing multiple, similar to security groups, that is where the biggest chunk of implementation work will be.
19:21:39 <mickeys> And adding VM ports.
19:22:08 <SridarK> mickeys: or the risk - i am not as familiar with that part of the code - so some investigation there is needed
19:22:42 <sc68cal> that's going to take a lot of work, and that only just deals with the new binding of firewalls to ports.
19:23:04 <sc68cal> all the new things we are adding to the firewall rule stuff is another big chunk of work
19:23:11 <SridarK> mickeys: some of it could just be my paranoia on the iptables - someone with more knowledge there could have more clarity
19:23:24 <sc68cal> SridarK: I think that paranoia is justified
19:23:26 <SridarK> sc68cal: +1
19:23:32 * sc68cal is a PF user
19:23:39 <SridarK> :-)
19:23:54 <mickeys> The basic code flow for security groups is quite different from FWaaS. FWaaS pushes all changes to the agent. Security groups notify all agents of changes, then agents pull what they need from the controller. If one firewall group changes but there are others on the same port, you need the contents of the other firewall groups to formulate the new iptables rules.
19:24:33 <sc68cal> mickeys: that was true - but I think recent changes have been moving to a push model for SG
19:25:10 <sc68cal> not sure, but I though there was some work done to change that
19:25:15 <sc68cal> could be wrong
19:25:47 <mickeys> Firewall group plus IP address (prefix) is parity with security groups. That leaves address groups and service groups as candidates to be deferred. There is also the change to firewall rule to firewall policy binding, but adding that later scares me.
19:26:29 <mickeys> sc68cal: I don't think that is changing. Kevin Benton's changes were inside the driver / iptables manager to only program the diff rather than replace everything
19:26:43 <mickeys> Unless there is something else happening that I don't know about?
19:26:49 <sc68cal> mickeys: ah ok no you are correct
19:27:08 <sc68cal> I knew there was some sort of partial diff, but didn't know if it was RPC layer or just inside the agent - had hoped at RPC layer
19:27:45 <mickeys> Not at RPC layer
19:27:57 <mickeys> The firewall rules / firewall policy binding is the other big technical issue in the spec, where we do not yet have consensus
19:28:02 <mickeys> Position or priority?
19:28:43 <SridarK> the push vs notify + pull - btwn plugin and agent - is an area we need to revisit as well - we had the implementation for FW as the push - but we will need to adapt that to be in sync with others
19:29:03 <sc68cal> right.
19:29:04 <SridarK> it seems position is easier to implement
19:29:09 <badveli> SridarK : yes and the  iptables  changes for  binding of firewalls to ports
19:29:23 <sc68cal> sadly we've got 30 seconds - let's continue in our IRC room
19:29:54 <sc68cal> #openstack-fwaas for those that don't know
19:30:03 <sc68cal> anyway, until next week
19:30:14 <jwarendt> Thanks
19:30:21 <SridarK> ok bye all
19:30:22 <sc68cal> #endmeeting