18:00:03 #startmeeting keystone 18:00:03 Meeting started Tue Jul 25 18:00:03 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:06 The meeting name has been set to 'keystone' 18:00:11 o/ 18:00:12 ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, notmorgan, rderose, rodrigods, samueldmq, spilla, aselius, dpar 18:00:18 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:00:22 agenda ^ 18:00:23 hey 18:00:24 o/ 18:00:28 hi o/ 18:00:29 o/ 18:00:41 o/ 18:01:31 o/ 18:01:45 #topic announcements: feature status 18:02:21 #link https://blueprints.launchpad.net/keystone/pike 18:02:34 this week is the deadline for all feature work 18:02:51 the biggest changes we have to go through is the project tags implementation 18:03:07 it looks like most of that is getting broken into smaller patch sets though 18:03:25 is everything in the same topic? 18:03:31 on gerrit, i mean 18:03:36 should be 18:03:39 cool 18:03:47 https://review.openstack.org/#/q/topic:bp/project-tags 18:03:51 thanks gagehugo 18:04:05 o/ 18:04:10 lbragstad: gagehugo I added a topic at the end to talk a bit on how we implement that 18:04:26 I have some suggestions/questions. would be great to discuss here 18:04:40 sounds good 18:05:20 I'll propose app creds and extend user API to support federated attributes to backlog 18:05:57 * samueldmq nods 18:06:03 that makes sense to me 18:06:29 #info application credentials will be bumped to Queens 18:06:48 #info extending the user API to support federated attributes will be bumped to Queens 18:06:56 #topic announcements: bugs 18:07:30 by EOW we're going to be in full bug mode 18:07:43 #link https://etherpad.openstack.org/p/keystone-pike-bugs 18:07:55 i'm going through all bugs opened in PIke and prioritizing accordingly 18:08:12 by the end of today - i should have a list of things targeted to pike-rc1 18:08:27 out target week for rc1 is going to be August 11th 18:08:37 which is about 3 weeks away 18:09:15 #topic default roles for domains 18:09:20 dpar o/ 18:09:27 this was on our agenda last week too 18:10:01 we'll circle back if dpar shows up 18:10:07 #topic project tags 18:10:12 samueldmq: gagehugo o/ 18:10:32 so, I was discussing a few points with gagehugo (and others involved) 18:10:38 regarding the current implementation 18:10:57 1) do we really need separate policies for the project-tags operations? 18:11:24 why not re-use the project's ones ? same rule of project_update for updating tags, for examples 18:11:27 example* 18:11:33 probably we do. 18:11:36 since tags IS an attribute of a project 18:12:01 we don't control any other attribute differently 18:12:10 why are tags that special? 18:12:58 are there other attributes that have their own urls? 18:13:04 i don't think so 18:13:07 i generally like the granularity. 18:13:21 eventually it would be great to be more granular 18:13:30 but we have so much work todo before we get to that point 18:13:34 also allows special project management software to be tied in without being given the keys to the cloud. 18:13:42 the current implementation makes the new rules default to what projects is 18:14:00 the naming of that rule_project_admin_required isn't very good 18:14:28 I'd go for re-using what we have (and being consistent with the rest of the attributes) 18:14:51 we would have to hack the protector then wouldn't we to do something special for project tags? 18:14:56 when we get to better policies (more granular), I hope we will be able to be more granular and check on the attributes 18:14:57 maybe a better question is - how hard would it be to break that out later and have project tags be separate? 18:15:24 if we're eventually going to more granular policies, why not start now with this? 18:15:42 knikolla that's what we thought 18:15:50 this will probably have to be changed in the future 18:15:58 it is weird though, tags is an attribute 18:16:19 knikolla: would be great to figure out how we will do that 18:16:33 maybe we will have the same policy, but will allow to check on different attributes within the policy rule 18:16:33 but it stands on it's own behind the scenes 18:16:45 I wouldnt change that all of a sudden. 18:16:59 and as pointed out by lbragstad, we can always expand that into several rules later 18:17:09 if that's what we want, and how we decide to go for more granular access 18:17:23 if we're restrictive to start out, it's easy to loosen the constraint later 18:17:29 can you imagine if we start adding new policy rules per resource'attribute 18:17:31 s/easy/easier/ 18:17:58 do you see other use cases for project attributes? and something that we will add often? 18:18:03 ig you think from the API point of view, tags is just a regular attribute of projects 18:18:07 i thought that was specifically shut down previously 18:18:08 at least this is how I see them 18:18:14 and tags was the most people agreed to add to projects 18:19:19 I am not disagreeing on adding tags to projects 18:19:25 so we can hack in to have tags follow the project policy, then fix it later. Or just create the rules now and be different from other attributes? 18:19:51 if we make it special/different, there is no way to get back from that. 18:20:08 specially because we dont have a deprecation workflow for policy rules yet 18:20:28 gagehugo: your project admins are going to be the ones using project tags, right? 18:20:32 starting how we do it nowadays, and making more granular (as we discover how to do that ) would be better imo 18:20:41 gagehugo: you don't need to have a separate role defined to manage project tags? 18:21:02 lbragstad ours will be yes, others might not? 18:21:30 if you reuse the project policies, does that require hacking the protected method? 18:21:45 That's what it looks like 18:22:07 will have to make a special case for if tags, enforce project policy 18:22:08 I'd be inclined to separate the policies specific to get around having a hack for it 18:22:23 gagehugo: all the new APIs for CRUDing policies are in accordance of what nova did, correct? 18:22:37 samueldmq for the most part yes 18:23:05 does nova has a separate policy for tags? 18:23:24 gagehugo: the part of having separate APIs for handling the tags (adding,removing) within resources... 18:23:52 i guess it doesn't really make much sense to have operators deal with tag policies in one project and not in another 18:23:53 lbragstad: that is a good question 18:24:06 lbragstad yes 18:24:18 they do have a separate policy for tags? 18:24:22 https://github.com/openstack/nova/blob/master/nova/policies/server_tags.py 18:24:41 ah ha 18:25:06 well - i suppose that's another reason to split it out into it's own policy (for consistency) 18:25:11 plus separate policies seemed easier than hacking the protector 18:25:24 which I do agree with samueldmq that it is weird 18:25:39 since the other attributes don't have them (yet?) 18:26:11 should we vote? 18:26:20 or do we have consensus 18:26:47 I am okay with adding new policies now 18:26:51 for consistency with nova 18:26:56 yeah - same here 18:27:07 would be great to try to use the same names they use 18:27:11 anyone else have objections to the approach? 18:27:15 or similar ones for the tags operations 18:27:23 so that it's not confusing to operators 18:27:30 samueldmq can def take a look 18:27:35 and let's add exactly the same operations on tags 18:27:41 yea 18:27:43 I guess we dont need to do more than they do 18:28:18 gagehugo: cool - anything else? 18:28:26 I think I have somehting else 18:28:31 just one more detail 18:28:33 samueldmq: go for it 18:28:52 why don;t we just re-use the project manager/drivers for handling the tags 18:29:13 maybe the manager, the driver needs to be separate as we have a different table? 18:29:28 that's an idea, of course would like to get some views on it 18:29:37 for the sake of simplifying the implementation 18:30:28 as of today, they don't share anything than the directory the code is in 18:30:40 I need to review that change 18:30:46 nevermind me. I guess it's sane to go for it as it is organized right now 18:30:57 and if we want to refactor we can do tht 18:31:03 it isn't a terrible amount of code 18:31:18 samueldmq it uses the same manager doesn't it? 18:31:29 yeah - we should be able to refactor it later, we've done that with the project and domain controllers/managers in the past 18:31:41 lbragstad: ++ 18:31:51 gagehugo: hmm I think so. maybe we could use the same driver? 18:32:10 I don't think there is a rule that says 1 driver - 1 table. I'd go 1 driver 1 entity. 18:32:21 and in this case the project is split in more than one table 18:32:32 but as I said, anyways. this is not the most important thing now 18:32:36 ok 18:32:43 the API/policy behavior is the key 18:32:57 let's shoot to follow the convention nova set 18:33:00 i gave a quick look and it seems sensible the way it's organized. 18:33:00 with server tags 18:33:16 lbragstad: ++ 18:33:20 anything else related to project tags? 18:33:29 gagehugo said he'll look at it and make us consistent 18:33:32 lbragstad: not from me, thanka 18:33:42 #topic open discussion 18:33:58 floor is open 18:33:59 you can always ping me too about questions, I will be around 18:34:11 or lamt 18:34:29 i'll be reviewing that stuff today 18:34:59 sure, I saw lamt has been updating some of those patches too 18:35:16 lbragstad: I will be going through the nova api-docs and make sure our implementation is consistent 18:35:19 that should be enough 18:35:36 works for me 18:35:47 looks like we can get some time back before office hours starts 18:36:01 thanks for coming! 18:36:06 please don't strive for consistency at the expense of other things. 18:36:06 #endmeeting