16:01:06 #startmeeting networking_policy 16:01:07 Meeting started Thu Jan 23 16:01:06 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:10 The meeting name has been set to 'networking_policy' 16:01:18 Hi 16:01:34 thinrichs: Hows it going? 16:01:48 hi banix! 16:01:49 Good--busy as always. How about you? 16:01:51 michsmit: yo! 16:01:58 thinrichs: Busy but happy :) 16:02:02 mestery: hi 16:02:03 hi 16:02:07 hi everybody 16:02:11 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda 16:02:13 hello 16:02:19 s3wong: Greetings! 16:02:27 Hi all 16:02:28 Looks like we have most of the team here. 16:02:36 songole_: howdy! 16:03:17 #topic Action Item Review 16:04:04 So, I setup a shared github for the PoC work for now. 16:04:16 I was thinking we could just use a github and merge code there, and then formulate patches for upstream later. 16:04:17 Thoughts? 16:04:28 #link https://github.com/mestery/neutron/tree/group_policy Shared github repository 16:04:34 mestery: sounds good 16:04:35 mestery: Thanks. Sounds good. 16:04:44 Cool! 16:04:48 mestery: that sounds good 16:04:59 So, it's just a clone of upstream Neutron for now, next step is to get the APIs in there I think. :) 16:05:05 One more action item to review 16:05:20 Thanks to s3wong for setting up the API document 16:05:22 #link https://docs.google.com/a/mestery.com/document/d/1b_ywmSTKYW4PBjhkXREPePRgVmz-Uwv_Bb-i7Jaqsu4/edit API Document 16:06:23 So, review comments on that document appreciated by folks. 16:06:35 yes, please 16:07:06 and if anyone else wants editing right, please let me know as well (just send request via document) 16:07:13 Thanks s3wong. 16:07:17 #topic PoC 16:07:24 s3wong: Do you have enough info to start coding up the APIs now? 16:08:02 mestery: yes, so I will be doing that over the next week or so 16:08:24 s3wong: Great! I'll start looking at the agent side as well for actually implementing things in OVS as well. 16:08:36 I have *just* started coding the model (the db tables). 16:08:39 (hopefully, other than songole, everyone else can do their part without waiting on me to finish) 16:08:46 s3wong: any access restrictions on APIs. admin vs tenant I suppose none. 16:09:08 songole: for now, I don't see any 16:09:23 banix: Great! I'll start the agent stuff as well then. 16:09:34 looks like for now the policy is defined within a tenant 16:10:18 Is that right? Anything we need to do to have policies defined across tenants? Are we assuming the admin could do that 16:10:47 i think if keystone scoping allows then apis should be allowed right? 16:11:06 A tenant could only specify an endpoint in his domain? 16:11:06 banix: I don't think there is anything we defined so far that is cross-tenant. Did I miss something? 16:11:09 prasadv: I think that makes sense, in which case admin would be able to work across tenants through keystone 16:11:25 s3wong: you are correct 16:11:31 May be not right now but something to think about / discuss. 16:11:59 Would there ever be a need for an admin to impose network-wide policies, i.e. that apply to every tenant? 16:12:02 prasadv, mestery: agree 16:12:20 I guess just "external network", if we put that into an endpoint group... (and expecting the group-policy implementation to say create a port on provider router) 16:12:38 yeah admin will be able to say see endpoints / groups defined by different tenants 16:12:40 s3wong: Makes sense 16:13:54 i guess there could be an issue when there is a conflict between what admin configures and say another role restericted to tenant configures 16:14:27 which one takes precedence? 16:14:50 prasadv: That gets into the conflict resolution stuff we talked about a few weeks back I think. 16:15:00 prasadv: So we had a simple conflict resolution mechanism 16:15:15 that should apply regardless of admin/tenant. Right? 16:15:28 But I think prasadv brings up an interesting case. 16:15:32 ok. I am thinking this is more of authorization policy right? 16:15:43 prasadv: that is an interesting case - so admin has some security group setup, and tenant's policy conflict with it? 16:15:47 We wouldn't want our admin to say 'drop', and the tenant to say 'allow', and for the tenant to win out. 16:15:56 I would guess in that case, admin will win? 16:16:10 I think in this particular case, keystone policy would have to win out. 16:16:10 s3wong: that's what we'd want, but right now there's no mechanism for that. 16:16:25 maybe this should be resolved by keystone and not by individual Openstack components 16:16:26 e.g. the admin user's group policy configuration supercedes the tenants 16:16:34 prasadv: Yes, that exactly. 16:16:49 mestery: but keystone won't be involved ... 16:16:53 mestery: ok 16:17:23 mestery: that makes the most sense 16:17:27 prasadv: I am not sure I see how this works 16:17:29 I'm confused: so Keystone is now accepting these policy rules we're creating here? 16:17:47 keystone is not really involved. Is it? 16:17:55 what I mean is whether a user has higher precence in terms of authorization is done by keystone 16:18:13 say admin supercedes tenant role 16:18:33 prasadv: You are saying keystone is consulted for conflict resolution? 16:18:54 When policies are created, won't they will have keystone auth attached to them, right? 16:19:04 not sure now where this role based conflict resolution takes place 16:19:38 i am sure this is not just a problem for neutron alone. This is a common problem across all of openstack right? 16:19:41 mestery: Ok, carry on 16:19:41 prasadv: I'm guessing the implementation has to ensure that the policy it eventually enforces takes all these conflict resolution schemes into account. 16:20:17 Is it possible for 2 different tenant policies to conflict? Both tenants having VMs on the same machine or something? 16:20:31 If so, the keystone-based conflict resolution won't work. 16:20:52 API calls into Neutron have tenant information attached banix, so we may need to take that into account when doing policy resolution is what I was thinking. 16:21:23 thinrichs: I think tenant roles need to be factored into the conflict resolution, but it's not the final resolution story for sure. 16:21:33 mestery: so conflict resolution is done at the API layer here? 16:21:51 At least for tenant resolution, maybe it has to be s3wong? 16:22:13 mestery: it appears so, actually 16:22:21 mestery: so at the creation of policy conflicts are detected? 16:22:41 banix: For tenant conflicts, maybe it has to be done then, yes. 16:22:42 I see what you are saying 16:23:07 Why do we need to resolve conflicts within the API? Can we have the API just create a bunch of policies with IDs attached, and the implementation compiles that down into the real policy it is implementing? 16:23:28 banix: more interestingly, if tenant has an 'allow', then later on admin adds an 'deny', we would have to find a way to inform tenant his policy fails? 16:23:29 thinrichs: That is the other approach I was thinking yes, not sure which approach has advantages. 16:23:29 thinrichs: agree 16:23:36 so if assume admin creates a policy after a tenant has already created a policy and there is conflict, something we need to figure out what to do then. 16:24:03 s3wong: that's what i was think about 16:24:04 We might need that more dynamic version anyway because users can change roles, which would require eliminating conflicts again. We wouldn't want to lose the policy rules they sent in initially. 16:25:11 thinrichs: shouldnt we just limit it during creation? instead of doing it dynamically? 16:25:38 What would happen if a user changes roles *after* they finished inserting their policies but they didn't login again? Would Neutron even know their roles changed and that conflict resolution should be revisited? 16:25:55 So just to narrow down the problem, our simple resolution method would be fine within a tenant. with checks done at policy creation time. Agree? 16:25:59 prasadv: Not sure--trying to understand the tradeoffs. 16:26:31 banix: not sure we'd do it at policy creation time. 16:26:33 There could be pert issues with dynamic conflict resolution. 16:26:41 thinrichs: Is there a workflow in Horizon/CLI to change a users role? I'm asking because I don't know off-hand. 16:26:46 banix: Suppose two classifiers overlap--do we reject the policy? 16:26:55 mestery: I don't know--I assumed user roles could change. 16:27:17 i think keystone provides user to be put into different roles 16:27:17 thinrichs: I'm asking because we may be boiling the ocean here without knowing hte workflow in existing OpenStack use cases. :) 16:27:28 thinrichs: Want to take an action item to figure that out? 16:27:33 thinrichs: yes 16:27:43 thinrichs: It would help us with resolution I think. :) 16:28:01 banix: Is it always easy to determine if classifiers overlap? 16:28:21 that would be a good idea. 16:28:27 mestery: I'll figure out if roles can be changed in Keystone. 16:28:33 to look into this more closely 16:28:39 #action thinrichs to determine if roles can be changed in keystone 16:28:41 thanks thinrichs! 16:28:45 NP 16:28:58 OK, lets move on from that discussion until we figure out the underlying keystone stuff for next week. 16:29:12 mestery: agree 16:29:17 mestery: yes 16:29:35 conflict resolution is an ongoing topic 16:29:36 OK, what else to discuss with regards to PoC this week? 16:29:44 Anything else? 16:29:53 It is really cold around here :) 16:30:06 banix: So cold school was canceled again today :) 16:30:06 banix: New York? 16:30:11 Minnesota here 16:30:17 s3wong: yes 16:30:31 * s3wong enjoying sunny California 16:30:48 Didn't hear the last sentence :) 16:30:50 BTW here's the info on Keystone. 16:30:51 s3wong: :P 16:30:53 user-project roles can be changed on the fly: http://docs.openstack.org/user-guide-admin/content/admin_cli_manage_projects_users.html 16:30:57 thinrichs: that was fast! 16:31:07 Had some help. 16:31:34 thinrichs: :) 16:31:52 thinrichs: seems like we need a mechanism to inform tenants that their policies may be invalidated 16:32:01 s3wong: My thoughts exactly 16:32:34 Let us think more about conflict resolution and perhaps discuss on ML? 16:32:46 s3wong: Getting complicated 16:32:53 s3wong, mestery: Isnt this a Openstack infrastrcuture issue and not just networking? 16:32:55 banix: Agreed! 16:33:00 prasadv: Yes 16:33:08 banix: Want to start the thread for the group on the ML? 16:33:12 and to avoid confusion, in an event of invalidation, I would say all policies need to be invalidated 16:33:21 for that tenant 16:33:28 Agreed to take it to the ML. 16:33:39 ML it is! 16:33:42 #action banix to start discussion around role changes on the ML 16:34:03 Anything else for this week with regards to PoC? 16:34:04 Will do 16:34:22 Happy coding, guys :-) 16:34:32 s3wong! Ha! 16:34:39 #topic Open Discussion 16:34:44 Anything else or should we call it early this week? 16:35:05 Thinrichs: Needless to say, please feel free to post to the ML regarding this. 16:35:05 another quick meeting, three in a row! 16:35:13 Yes! 16:35:26 OK, lets see what we can get done with regards to PoC code for next week then. 16:35:27 Sounds good 16:35:28 Thanks everyone! 16:35:30 #endmeeting