00:01:04 <SridarK> #startmeeting Networking FWaaS
00:01:05 <openstack> Meeting started Thu Dec 10 00:01:04 2015 UTC and is due to finish in 60 minutes.  The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:08 <openstack> The meeting name has been set to 'networking_fwaas'
00:01:15 <SridarK> #chair SridarK xgerman
00:01:16 <openstack> Current chairs: SridarK xgerman
00:01:33 <xgerman> #topic midcycle
00:01:34 <bharathm> o/
00:01:36 <xgerman> #link https://etherpad.openstack.org/p/lbaas-mitaka-midcycle
00:01:59 <xgerman> they now have hotels. I recommend the ones near the airport
00:03:17 <SridarK> xgerman: thanks, i am waiting on travel approval
00:04:04 <mickeys> I will get approval. Not yet sure when I get to the point to actually book travel.
00:04:04 <xgerman> well, they have motels near the RAX office :-)
00:04:11 <Aish> o/
00:05:09 <mickeys> Downtown sounds like more fun than the airport?
00:05:33 <xgerman> RAX is near the airport so you are saving the drive in the morning
00:05:48 <xgerman> which is key since they are two hours ahead
00:06:17 <mickeys> Fine. I will move downtown for the weekend :-)
00:06:35 <xgerman> Valencia is a really nice place ;-)
00:07:00 <SridarK> xgerman: also in terms of agenda - we will do fwaas all 4 days or u see some breakup ?
00:07:27 <SridarK> with an lbaas focus on some days - to help folks like u who overlap both projects ?
00:07:43 <xgerman> yep, that’s my plan
00:08:12 <xgerman> but I should be 90% FWaaS
00:08:40 <mickeys> If FWaaS is only a subset of the days, I prefer skipping the first part of the week and focusing on the later part of the week. If we meet the whole time, that is OK as well.
00:08:47 <SridarK> ok wanted to be sure - so if we are not on fwaas all 4 days - can make travel arrangements
00:09:05 <SridarK> mickeys: +1
00:09:34 <mickeys> I will be stuck in Texas until the middle of the following week
00:10:19 <xgerman> I am fine with either. We can start Wednesday or use the time for more coding
00:10:29 <SridarK> makes sense - i wanted to optimize my time as well with some internal stuff so will be good to figure this out
00:10:38 <xgerman> I get less interrupted when I am off site ;-)
00:11:13 <jwarendt> I can fix that
00:11:49 <SridarK> i hope jwarendt: & Aish: can make it as well
00:12:10 <xgerman> still trying to get more travel money
00:12:47 <jwarendt> Waiting on travel approvals for some of us; will be there if can be and engaged regardless
00:13:00 <SridarK> sounds good
00:13:22 <Aish> Yup. The same as jwarendt said.
00:13:58 <SridarK> xgerman: may be u can think thru if it is Wed or Tue and sync with sc68cal: and then we can decide on travel dates
00:14:35 <xgerman> well, let’s just pick one. I will be there the whole week… so whatever works for you...
00:15:06 <xgerman> we had people come and go in previous mid cycles...
00:15:21 <xgerman> and some might leave early Friday...
00:16:02 <xgerman> anyway, let’s move on
00:16:15 <xgerman> #topic FWaaS API V2 spec
00:16:33 <SridarK> Aish: thanks for the updates
00:16:38 <xgerman> +1
00:16:39 <mickeys> +1
00:16:46 <Aish> I am working on a new patch right now.
00:17:00 <SridarK> i think we are in decent shape and may be a few nits
00:17:30 <Aish> yup, will be fixing those nits.
00:17:32 <xgerman> yeah, I will try to push for approval so we can start working
00:17:42 <xgerman> (dougwig ahem?)
00:18:15 <xgerman> mickeys you wanted to look at the Security Group workflow?
00:18:18 <mickeys> In the data model, firewall policy rule associations, priority needs to be CRU rather than just R
00:18:46 <Aish> ok..
00:19:40 <SridarK> mickeys: on the spillover discussion from last week - we were leaning more towards position for simplicity and look at priority later ?
00:19:45 <mickeys> I wonder whether we have complete consensus on position versus priority. To me, priority means that the user provides the value, not necessarily sequential, and that there can be conflicts (same priority value) which need to be resolved deterministically. Position means sequential with no conflicts, with insert_before, insert_after stuff.
00:20:11 <SridarK> mickeys: u answered my question :-)
00:20:22 <mickeys> Except I did not pick one ...
00:20:26 <xgerman> well, we can keep priority in the data model anyway
00:20:45 <xgerman> and we can throw CONFLICT when the priority already exists
00:21:10 <mickeys> The attribute was already moved to the firewall policy rule association. Now we have to agree on the term and the semantics.
00:21:30 <SridarK> things like conflict resolution adds to the complexity - but not doing resolution is certainly an approach
00:21:33 <mickeys> Do people agree with my definition above? Any preference?
00:21:54 <xgerman> priority since then we can have all kinds of integers (even negative)
00:22:06 <SridarK> +1 on the move to the policy rule association
00:22:16 <jwarendt> I prefer priority, since position changes with every insert.
00:22:54 <SridarK> i am still on the wall w.r.t to position and priority - mainly due to complexity in what we need to do in terms of implementation now
00:22:54 <badveli> currently we can specify the insert_before and after is there a problem
00:22:55 <mickeys> The API has insert_before, insert_after. Do we see that staying? Or do see that changing? If we change it, where would that go in the API? We don't have an explicit firewall policy rule association in the API.
00:23:43 <mickeys> The argument for position is minimizing changes to the API
00:24:35 <xgerman> well,  I think position-before/after are independent if we use priority or not
00:25:22 <xgerman> I also don;t think priority makes it more complex if we don’t allow overlapping ones
00:25:41 <mickeys> If you insert_before, what if there is no priority value in between the previous rule and the rule you are inserting before? Does the value change for rules other than the one being inserted?
00:26:43 <xgerman> you would change the priority… but I also like specifying it explicitly better
00:27:24 <mickeys> Right now there is just an ordered list of rules in a policy, so it is not explicit in the current API or the current proposal. Do we want to change that?
00:28:49 <xgerman> I am thinking of changing it to be more flexible...
00:29:45 <xgerman> but channeling my inner sc68cal he would probably like us to minimize changes
00:30:00 <mickeys> The simplest option is to put it in the rule, but that may affect your ability to reuse rules. If everything else is identical but you need to insert in a different place within another policy, do you have to replicate the rule just to specify a different priority value?
00:30:02 <SridarK> xgerman: i would align with that
00:30:28 <mickeys> I do think position minimizes changes
00:30:43 <jwarendt> Only if a rule is only 1 to 1.
00:31:00 <jwarendt> Position 2 means different things to different ordered lists
00:31:24 <jwarendt> But both have issues
00:31:38 <mickeys> We took position out of firewall rule for that reason. It was read only. The actual configuration is through the ordered list of rules in the policy.
00:32:13 <mickeys> If position is only in the ordered list of rules in the policy, then position can vary for the same rule, when it is bound to different firewall policies
00:32:27 <SridarK> essentially the attribute which one it is also tied to the policy that the specific (shareable) rule will be associated to
00:32:40 <SridarK> *whichever one
00:33:40 <Aish> mickeys: +1
00:34:18 <mickeys> For priority, it seems like you either need to make the ordered list a list of (rule, priority) tuples (somewhat ugly), or you would need to add an explicit firewall rule / firewall policy association in the API, which adds complexity
00:34:36 <xgerman> I was thinking tuples
00:35:45 <xgerman> but I think we will end up with the same result whatever we choose...
00:37:50 <bharathm> Though Priority seems to add flexibility and future proof,, I am inclined towards Position (with insert_before/after) for its ease of implementation
00:38:25 <xgerman> I sense we settled on position...
00:38:35 <xgerman> so let’s do that
00:38:44 <jwarendt> Security groups don't really need ordering, since just a whitelist, so just make sure that we don't kill distributed functionality by using a global lock with client required knowledge of ordering state or something similarly stupid when not needed.
00:39:38 <SridarK> i still think we can move the attribute to the policy - rule association table
00:39:54 <xgerman> yeah, that for sure
00:39:59 <mickeys> SridarK: The data model already reflects that
00:40:05 <SridarK> and the API will be experimental so we can come back to this
00:40:05 <xgerman> +1
00:40:09 <bharathm> +1 on policy-rule association
00:40:17 <SridarK> mickeys: yes just want re iterate
00:41:43 <mickeys> Are we agreed to start with position? Once we get things running, anyone can propose changing it to priority if they think it is important?
00:42:01 <xgerman> well, it’s hard to make API changes like that
00:42:20 <xgerman> but yes, let’s run with that
00:42:50 <SridarK> xgerman: i think we should get a pass for at least the N cycle
00:42:56 <SridarK> as things settle in
00:43:32 <xgerman> well, I just had Horizon blow me off because they felt the LBaaS API wa sunstable
00:43:39 <xgerman> aka in not finalized
00:44:05 <xgerman> (which is entirely not true BTW)
00:45:38 <xgerman> so what I am saying is if we think we need it in the next two cycles we should do it now...
00:46:24 <xgerman> since the earlier we can declare we are done with changes we can get heat and horizon engaged
00:48:22 <SridarK> i agree with u on that aspect, my concern is really on how much we can get done. IMO, the port binding  and getting the SG interactions right could consume significant cycles
00:49:25 <xgerman> yeah, usually API’s are fast the problem is in those peaky drivers ;-)
00:49:34 <SridarK> :-)
00:49:45 <mickeys> To avoid going in circles, perhaps we should leave the API as is in the next patch set, then German can make a comment with the replacement text to change the API to a (rule, priority) tuple, then we can all comment whether we like it or not?
00:50:00 <SridarK> sounds like a plan
00:50:01 <jwarendt> Sounds good to me.
00:50:03 <xgerman> +1
00:50:05 <bharathm> +1
00:50:12 <Aish> +1
00:50:16 * xgerman likes going in circles reminds me of a carousel
00:50:33 <SridarK> :-)
00:50:37 <xgerman> well, next topic
00:50:48 <xgerman> in the API we need to discuss...
00:51:09 <xgerman> Aish?
00:52:34 <mickeys> Should we move on to service groups?
00:52:38 <xgerman> yes
00:52:43 <xgerman> #topic service groups
00:52:54 <mickeys> Several issues where we have not yet reached consensus
00:53:07 <mickeys> 1) Firewall rule specifies a single service group, or a list of service groups?
00:53:18 <mickeys> I prefer single service group
00:53:34 <SridarK> mickeys: yes this was driven earlier as a collection
00:53:49 <mickeys> And do people think we really need a list of lists?
00:53:58 <xgerman> no, no list of list
00:54:04 <SridarK> possible we can live without this
00:54:09 <mickeys> Service group is already a list of service objects
00:54:30 <SridarK> i think this came from a requirement of reusing a list
00:54:39 <SridarK> but i think we can live without it
00:54:41 <mickeys> Badveli: Your argument for a list of service groups?
00:55:44 <SridarK> not sure if badveli: is around but we can discuss this with him
00:56:01 <mickeys> badveli's reply in the comments: A firewall rule can specify multiple service groups, since the usability of the service groups is not tailored for any specific use case. As mentioned the service groups are meant to be reusable across tenants we do not want to tailor one service groups and ask everyone to use it, one service groups need not be overloaded even it is a list of service objects, instead they can choose which service groups
00:56:01 <mickeys> they want.
00:56:13 <badveli> yes
00:56:49 <mickeys> I still prefer the simplicity of a single service group in a firewall rule
00:56:51 <mickeys> Others?
00:56:52 <badveli> but it gets complicated when we say multiple service groups
00:57:21 <badveli> already currently the service groups can have multiple service objects
00:57:38 <badveli> and the reverse way
00:57:59 <SridarK> badveli: so that helps (multiple serv obj)
00:58:19 <SridarK> so if there isnt a compelling need we can avoid this ?
00:58:30 <SridarK> time check 2 mins
00:58:30 <xgerman> yep, no lists
00:58:30 <badveli> SridarK: currently the ideal scenario is multiple service groups in firewall
00:58:39 <badveli> multiple service objects in service groups
00:58:55 <SridarK> badveli: maybe we discuss more on gerrit
00:58:56 <badveli> but this gets more complicated
00:58:58 <xgerman> let’s start with 1:1 and expand if we find the use case
00:59:01 <badveli> ok, thanks
00:59:15 <badveli> that is the reason we say our intentions but modelling wise
00:59:20 <badveli> i had restrictions
00:59:57 <SridarK> we also want to see when we want service groups implemented
00:59:58 <badveli> xgerman: then the spec should not mention the multiple service objects in service group vice versa
01:00:08 <xgerman> k, I am on vacation until the end of the year. Most teams do next week and then skip for the re
01:00:18 <xgerman> st of the year
01:00:44 <xgerman> well, ML...
01:00:50 <xgerman> #endmeeting