18:00:43 #startmeeting networking_policy 18:00:43 Meeting started Thu Aug 13 18:00:43 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:46 The meeting name has been set to 'networking_policy' 18:01:09 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Aug_13th.2C_6th.2C_2015 18:01:18 hi 18:01:18 hi 18:01:23 lets mostly focus on the release 18:01:42 i think we are on track for tomorrow 18:02:28 we will discuss the bugs and the high priority issues, but at a high level does anyone have any concerns with going forward with the release in the next couple of days? 18:02:54 rkukura: Yi: hi 18:03:23 okay, so seems like we are fairly comfortable 18:03:32 #topic Bugs 18:03:54 hi 18:04:24 i would mostly like to discuss the bug fixes that I believe will good to have merged before the release is cut 18:04:58 #link https://bugs.launchpad.net/group-based-policy/+bug/1479169 18:04:58 Launchpad bug 1479169 in Group Based Policy "GBP default security group allows outbound access to the Internet" [High,In progress] - Assigned to Ivar Lazzaro (mmaleckk) 18:05:12 the patch is here: #link https://review.openstack.org/#/c/207250/ 18:05:49 ivar-lazzaro: could you quickly summarize the change (will help the reviewers) 18:07:04 sure 18:07:24 basically the issue is in how we do outgoing security today in GBP 18:07:35 ivar-lazzaro: right 18:07:55 so far, we have been allowing all the outgoing traffic for any new classifier (eg. port 80 ALLOW 0.0.0.0/0 direction OUT) 18:08:21 the reason why we did this is that we could always filter incoming traffic 18:08:32 ivar-lazzaro: true 18:08:45 This assumption doesn't held true with External Policies 18:09:20 where we have no control over the Internet, and therefore we can't filter traffic on the other side of the fence 18:09:41 ivar-lazzaro: right 18:09:54 So this change makes sure that we do a granular outgoing filtering depending on who is consuming/providing a given contract 18:10:26 instead of 0.0.0.0/0 for outgoing, we will allow traffic only for providing/consuming EPG-Subnets 18:10:45 ivar-lazzaro: so how do you deal with external connectivity? 18:10:59 That's based on the routes 18:11:05 in the external_segment 18:11:29 further ahead, this could be done based on the subnet specified in the EP itself 18:11:36 ivar-lazzaro: Does your patch always do the egress filtering, or only when the other side is external? 18:11:36 but we don't have that kind of support yet 18:11:45 rkukura: always 18:12:12 rkukura: the advantage is that we can block traffic before it reaches the destination, saving some bandwidth 18:12:33 makes sense, and its twice as secure ;) 18:13:00 ivar-lazzaro: i am not clear about the “based on the routes” part 18:13:17 SumitNaiksatam: each External Segment has a set of routes that it serves 18:13:48 the outgoing filter is calculated as the IPSet difference between the internal L3P pool and that set of routes 18:14:02 for example, if you have a L3P with 192.168.0.0/16 as a pool 18:14:16 and an external segment that servers 0.0.0.0/0 (most common case) 18:14:36 the rule is filtered by IPSer(external) - IPSet(internal) 18:14:54 that is all the CIDRs that are contained in the external segment but not in the L3P 18:15:17 (Otherwise we would lose the advantage of filtering outgoing EAST-WEST traffic as well 18:15:35 ivar-lazzaro: okay, but i believe we were already doing that before, right? 18:15:49 needless to say, this patch made me think that the FWaaS API seems way more suitable for this kind of N-S filtering :) 18:15:58 SumitNaiksatam: only for ingress 18:16:05 SumitNaiksatam: now it's done for egress as well 18:16:15 ivar-lazzaro: okay 18:16:44 ivar-lazzaro: thanks for the explanation 18:17:32 this is an imp we fix we need to get in, otherwise we allow external connectivity even when there is no external policy providing it 18:17:58 SumitNaiksatam: I can review it today 18:18:03 rkukura: great, thanks 18:18:39 #link https://bugs.launchpad.net/group-based-policy/+bug/1481973 18:18:39 Launchpad bug 1481973 in Group Based Policy "wrong IP allocation for multiple PTGs in same L2P" [Undecided,New] 18:18:57 fix is #link https://review.openstack.org/#/c/209700/ 18:19:26 yeee, it's me again! :) 18:19:31 i think this is pretty straightforward 18:19:50 ivar-lazzaro: i just had the comment to add another exisitng bug to the commit 18:19:59 since i believe it fixes that issue as well 18:20:18 ok I'll give a look 18:20:18 SumitNaiksatam: I’ll review that one too. 18:20:32 ivar-lazzaro: rkukura: thanks 18:21:19 #link https://review.openstack.org/197973 18:21:28 #link https://bugs.launchpad.net/group-based-policy/+bug/1470815 18:21:28 Launchpad bug 1470815 in Group Based Policy "NCP Plugin does not handle Service chain Instance update and Spec update correctly" [High,In progress] - Assigned to Magesh GV (magesh-gv) 18:21:45 i think we discussed this and the other patch briefly last week 18:22:14 mageshgv: this particular one is good to go? 18:22:36 mageshgv: i think it might help to rebase and let the gate run on it one more time 18:22:41 SumitNaiksatam: Yes, this is ready for review 18:22:49 SumitNaiksatam: will do it now 18:23:07 mageshgv: thanks 18:23:42 and the associated bug: #link https://bugs.launchpad.net/group-based-policy/+bug/1446587 18:23:42 Launchpad bug 1446587 in Group Based Policy "Service chain related parameter updates are too disruptive" [High,In progress] - Assigned to Magesh GV (magesh-gv) 18:23:50 and patch: #link https://review.openstack.org/#/c/198639/ 18:23:58 mageshgv: you will be updating the patch 18:24:03 per ivar-lazzaro’s comment? 18:24:26 right, This patch needs an update. was unable to find a way to add the first patch as a dependency 18:24:47 so waiting for the other one to be reviewed and merged 18:24:51 mageshgv: oh 18:25:13 mageshgv: I typically cherry pick them one on top of the other 18:25:22 mageshgv: and then push the whole thing 18:25:35 *review* 18:25:41 ivar-lazzaro: thanks, will give that a try 18:26:05 mageshgv: Another way is to pull in the patch, make it a branch, and rebase your branch on that branch. 18:26:20 rkukura: okay 18:26:54 rkukura: in the past i recall having used in that approach, thanks 18:28:00 seems like the quota one just merged #link https://review.openstack.org/#/c/208200/ 18:28:08 rkukura: mageshgv: thanks for taking a look 18:28:52 the other one i had on my list was this: #link https://bugs.launchpad.net/group-based-policy/+bug/1460831 18:28:52 Launchpad bug 1460831 in Group Based Policy "API for group update is not clear" [High,Confirmed] - Assigned to Sumit Naiksatam (snaiksat) 18:29:02 patch: #link https://review.openstack.org/#/c/209409/ 18:29:18 i still need to post a follow up patch set 18:29:22 rkukura: thanks for the review 18:29:47 i thought the above will be go to get in now, that way we can deprecate the older option over the course of liberty 18:30:46 okay, so that’s a list of currently posted patches that i thought have significant impact and can be handled in a day or two of reviews 18:31:42 we will always have the option posting further bug fixes and backporting 18:32:05 mageshgv: ivar-lazzaro rkukura: anything critical that we missed? 18:32:56 #topic Open Discussion 18:33:22 if not i would like to open it up, so that we can wrap up early today and focus on the identified patches and reviews 18:33:37 anything else we need to discuss? 18:34:27 alright, thanks everyone, back to the reviews! ;-) 18:34:37 Thanks! bye 18:34:40 bye! 18:34:41 bye 18:34:43 #endmeeting