00:01:04 #startmeeting Networking FWaaS 00:01:05 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:08 The meeting name has been set to 'networking_fwaas' 00:01:15 #chair SridarK xgerman 00:01:16 Current chairs: SridarK xgerman 00:01:33 #topic midcycle 00:01:34 o/ 00:01:36 #link https://etherpad.openstack.org/p/lbaas-mitaka-midcycle 00:01:59 they now have hotels. I recommend the ones near the airport 00:03:17 xgerman: thanks, i am waiting on travel approval 00:04:04 I will get approval. Not yet sure when I get to the point to actually book travel. 00:04:04 well, they have motels near the RAX office :-) 00:04:11 o/ 00:05:09 Downtown sounds like more fun than the airport? 00:05:33 RAX is near the airport so you are saving the drive in the morning 00:05:48 which is key since they are two hours ahead 00:06:17 Fine. I will move downtown for the weekend :-) 00:06:35 Valencia is a really nice place ;-) 00:07:00 xgerman: also in terms of agenda - we will do fwaas all 4 days or u see some breakup ? 00:07:27 with an lbaas focus on some days - to help folks like u who overlap both projects ? 00:07:43 yep, that’s my plan 00:08:12 but I should be 90% FWaaS 00:08:40 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 ok wanted to be sure - so if we are not on fwaas all 4 days - can make travel arrangements 00:09:05 mickeys: +1 00:09:34 I will be stuck in Texas until the middle of the following week 00:10:19 I am fine with either. We can start Wednesday or use the time for more coding 00:10:29 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 I get less interrupted when I am off site ;-) 00:11:13 I can fix that 00:11:49 i hope jwarendt: & Aish: can make it as well 00:12:10 still trying to get more travel money 00:12:47 Waiting on travel approvals for some of us; will be there if can be and engaged regardless 00:13:00 sounds good 00:13:22 Yup. The same as jwarendt said. 00:13:58 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 well, let’s just pick one. I will be there the whole week… so whatever works for you... 00:15:06 we had people come and go in previous mid cycles... 00:15:21 and some might leave early Friday... 00:16:02 anyway, let’s move on 00:16:15 #topic FWaaS API V2 spec 00:16:33 Aish: thanks for the updates 00:16:38 +1 00:16:39 +1 00:16:46 I am working on a new patch right now. 00:17:00 i think we are in decent shape and may be a few nits 00:17:30 yup, will be fixing those nits. 00:17:32 yeah, I will try to push for approval so we can start working 00:17:42 (dougwig ahem?) 00:18:15 mickeys you wanted to look at the Security Group workflow? 00:18:18 In the data model, firewall policy rule associations, priority needs to be CRU rather than just R 00:18:46 ok.. 00:19:40 mickeys: on the spillover discussion from last week - we were leaning more towards position for simplicity and look at priority later ? 00:19:45 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 mickeys: u answered my question :-) 00:20:22 Except I did not pick one ... 00:20:26 well, we can keep priority in the data model anyway 00:20:45 and we can throw CONFLICT when the priority already exists 00:21:10 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 things like conflict resolution adds to the complexity - but not doing resolution is certainly an approach 00:21:33 Do people agree with my definition above? Any preference? 00:21:54 priority since then we can have all kinds of integers (even negative) 00:22:06 +1 on the move to the policy rule association 00:22:16 I prefer priority, since position changes with every insert. 00:22:54 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 currently we can specify the insert_before and after is there a problem 00:22:55 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 The argument for position is minimizing changes to the API 00:24:35 well, I think position-before/after are independent if we use priority or not 00:25:22 I also don;t think priority makes it more complex if we don’t allow overlapping ones 00:25:41 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 you would change the priority… but I also like specifying it explicitly better 00:27:24 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 I am thinking of changing it to be more flexible... 00:29:45 but channeling my inner sc68cal he would probably like us to minimize changes 00:30:00 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 xgerman: i would align with that 00:30:28 I do think position minimizes changes 00:30:43 Only if a rule is only 1 to 1. 00:31:00 Position 2 means different things to different ordered lists 00:31:24 But both have issues 00:31:38 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 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 essentially the attribute which one it is also tied to the policy that the specific (shareable) rule will be associated to 00:32:40 *whichever one 00:33:40 mickeys: +1 00:34:18 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 I was thinking tuples 00:35:45 but I think we will end up with the same result whatever we choose... 00:37:50 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 I sense we settled on position... 00:38:35 so let’s do that 00:38:44 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 i still think we can move the attribute to the policy - rule association table 00:39:54 yeah, that for sure 00:39:59 SridarK: The data model already reflects that 00:40:05 and the API will be experimental so we can come back to this 00:40:05 +1 00:40:09 +1 on policy-rule association 00:40:17 mickeys: yes just want re iterate 00:41:43 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 well, it’s hard to make API changes like that 00:42:20 but yes, let’s run with that 00:42:50 xgerman: i think we should get a pass for at least the N cycle 00:42:56 as things settle in 00:43:32 well, I just had Horizon blow me off because they felt the LBaaS API wa sunstable 00:43:39 aka in not finalized 00:44:05 (which is entirely not true BTW) 00:45:38 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 since the earlier we can declare we are done with changes we can get heat and horizon engaged 00:48:22 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 yeah, usually API’s are fast the problem is in those peaky drivers ;-) 00:49:34 :-) 00:49:45 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 sounds like a plan 00:50:01 Sounds good to me. 00:50:03 +1 00:50:05 +1 00:50:12 +1 00:50:16 * xgerman likes going in circles reminds me of a carousel 00:50:33 :-) 00:50:37 well, next topic 00:50:48 in the API we need to discuss... 00:51:09 Aish? 00:52:34 Should we move on to service groups? 00:52:38 yes 00:52:43 #topic service groups 00:52:54 Several issues where we have not yet reached consensus 00:53:07 1) Firewall rule specifies a single service group, or a list of service groups? 00:53:18 I prefer single service group 00:53:34 mickeys: yes this was driven earlier as a collection 00:53:49 And do people think we really need a list of lists? 00:53:58 no, no list of list 00:54:04 possible we can live without this 00:54:09 Service group is already a list of service objects 00:54:30 i think this came from a requirement of reusing a list 00:54:39 but i think we can live without it 00:54:41 Badveli: Your argument for a list of service groups? 00:55:44 not sure if badveli: is around but we can discuss this with him 00:56:01 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 they want. 00:56:13 yes 00:56:49 I still prefer the simplicity of a single service group in a firewall rule 00:56:51 Others? 00:56:52 but it gets complicated when we say multiple service groups 00:57:21 already currently the service groups can have multiple service objects 00:57:38 and the reverse way 00:57:59 badveli: so that helps (multiple serv obj) 00:58:19 so if there isnt a compelling need we can avoid this ? 00:58:30 time check 2 mins 00:58:30 yep, no lists 00:58:30 SridarK: currently the ideal scenario is multiple service groups in firewall 00:58:39 multiple service objects in service groups 00:58:55 badveli: maybe we discuss more on gerrit 00:58:56 but this gets more complicated 00:58:58 let’s start with 1:1 and expand if we find the use case 00:59:01 ok, thanks 00:59:15 that is the reason we say our intentions but modelling wise 00:59:20 i had restrictions 00:59:57 we also want to see when we want service groups implemented 00:59:58 xgerman: then the spec should not mention the multiple service objects in service group vice versa 01:00:08 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 st of the year 01:00:44 well, ML... 01:00:50 #endmeeting