18:05:27 #startmeeting keystone 18:05:28 Meeting started Tue Feb 23 18:05:27 2016 UTC and is due to finish in 60 minutes. The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:05:29 #link https://launchpad.net/keystone/+milestone/mitaka-3 18:05:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:05:32 The meeting name has been set to 'keystone' 18:05:33 gyee: you have to start it! 18:05:53 now GTFBTW! 18:05:53 #topic mitaka-3 release countdown 18:05:56 Yay 18:06:15 #link https://launchpad.net/keystone/+milestone/mitaka-3 18:06:25 wow that was so weird 18:06:27 back now 18:06:29 half my keys were not responding 18:06:37 shadow users High Ron De Rose Good progress 18:06:37 reseller (phase 1): top level projects as domains High Raildo Mascena de Sousa Filho Needs Code Review 18:06:41 5 out of the 6 needed patches for projecst acting as domains have npw merged, one to go (which is the main one): https://review.openstack.org/#/c/231289/ 18:06:44 stevemar, supernatural events 18:06:45 Project Tree Deletion/Disabling Medium Rodrigo Duarte Needs Code Review 18:06:49 stevemar: you made your mac mad 18:06:55 dstanek: clearly! 18:06:56 I think we should retarget owner on that last one, its not rodrigods 18:07:08 ayoung: you can put me on that 18:07:18 * rodrigods is reviewing the code 18:07:28 specs, whatever 18:07:31 htruta, will do. and 18:07:44 stevemar: using a mac :P 18:07:48 rodrigods is still involved, just not actively writign code; looks like it is 18:07:57 https://review.openstack.org/#/q/topic:project-tree-deletion-bug,n,z 18:08:13 Paulo Ewerton Gomes Fragoso and Samuel de Medeiros Queiroz with outstanding reviews 18:08:26 my list of patches that need to land: http://paste.openstack.org/show/487927/ 18:08:50 ayoung: I'm doing the redesign related to henrynash comment on the update cascade patch 18:08:54 aysyd: I don't really care for owning/coauthoring it, just getting the thing done 18:09:00 shadow users: https://review.openstack.org/#/c/278570/ 18:09:00 reseller: https://review.openstack.org/#/c/231289/ 18:09:00 projects as domains: https://review.openstack.org/#/c/243585/ 18:09:12 raildo, I think leave it as is unless henrynash can make his rationale more specific 18:09:12 stevemar: the last one is project tree deletion/update 18:09:14 ayoung: not aysyd ^ 18:09:23 those patches need reviewing ^ 18:09:43 ayoung: well, it doesn’t actually work as wirtten 18:09:52 I thought we are delaying reseller no? 18:09:58 henrynash, minor point, hardly worth mentioning 18:10:03 gyee: this is the first half of reseller 18:10:14 henrynash: ayoung: yes, see https://review.openstack.org/#/c/283168/ 18:10:15 henrynash, are you against the concept of the cascade check? 18:10:27 ayoung: not at all 18:10:35 ayoung: he agrees with the cascade check, but that isn't what the patch is doing 18:10:38 ayoung: we discussed earlier and we have some stuffs to fix/refactoring 18:10:41 ayoung: henrynash so let's talk about the update/delete cascade 18:10:45 see https://review.openstack.org/#/c/283168/ 18:10:51 OK...drive on then 18:10:52 that's bug current bug in that code ^ 18:11:19 the current implementation relies on the person doing the cascade delete to have a role on all subprojects 18:11:31 current *proposed* implementation 18:11:34 ugh. ok I get it 18:11:50 henrynash says nope! 18:11:52 stevemar: we have a issue to perform the check_protection in the subprojects 18:12:00 so i made two proposals: 18:12:18 * ayoung wonders how LDAP handles this 18:12:36 I think this cascading delete is going to be messy, especially if we have to coordinate project-owned resource cleanup in other services 18:12:56 1) use the current ckeck each project approach, but DON’t to teh code check for a role-per-project and just let teh plicy call handle each one (but you need to fake up the creds on each plkcy call) 18:12:57 gyee, it is done the same way as deleting a single project? 18:13:12 i think keystone send notifications for each project 18:13:13 2) have as separate policy endpint for teh cascade option 18:13:15 gyee: and the same way as deleting a domain too 18:13:17 rodrigods, we are deleting the whole tree 18:13:20 at least, should 18:13:45 the idea is to do exactly what would be done by deleting node by node 18:13:51 at all levels 18:13:56 from authz to bd changes 18:14:00 rodrigods: yes, keystone send a notification for each delete request 18:14:00 db* 18:14:18 henrynash, I think it makes sense to follow the LDAP example here: in LDAP, you need Delete permission on each node 18:14:49 if we do 1) correctly, then the policy writer can eitehr require a given role on each project, or could allow an overide for say domain_admin to do it without having a role on each project 18:14:53 so...not 2 18:15:17 we probably ended up needing some sort of lifecycle management framework 18:15:36 henrynash, we can do a role check, though, based on the current credential passed in. I think 1) will work, if I understand you correctly 18:15:36 and samueldmq and I discussed this earlier and agreed a proposed implementation 18:17:07 henrynash: ++ 18:17:18 henrynash, OK, so 1) it is? Works for me 18:17:24 ayoung: which will allow you to require given role per project, but also, if required, to allow a policy writer to demand additiona roles, or even to ban use of cascade if they so wish 18:17:24 I argue for cascade operations being a sort of shortcut 18:17:42 just saving time, but acting the same as a bunch of individual updates/deletes 18:17:48 so option 1 18:17:52 agreed 18:18:44 i'm okay with 1 - i believe that is what is proposed today in the patch? 18:19:08 stevemar: no, today if policy enforcement passes in the root 18:19:11 stevemar: it is the closest 18:19:23 stevemar: and you have any role in the subtree (any role, it really oesn't matter), ti passes 18:19:30 stevemar: yes, we just have to fix the (fake up the creds stuffs) 18:19:50 OK. We have a plan. Anything else need discussing on reseller or the other two>? 18:20:01 reseller needs reviews 18:20:21 ayoung: on reseller….yep, last patch needs reviews….cinder have fixed their quotas 18:20:24 henrynash did the last one on the 20th https://review.openstack.org/#/c/231289/ 18:20:42 i think the +623, -176 is scaring folks :) 18:20:51 henrynash, :"last" being which>? 18:20:53 stevemar: when is the last day for cutting m-3? 18:21:05 ayoung: https://review.openstack.org/#/c/231289/ 18:21:05 stevemar: or a better question, when are you going to cut it ? :) 18:21:07 29th 18:21:09 probably broken now due to migration # 18:21:14 bknudson: yep 18:21:21 samueldmq: 29th 18:21:32 so, monday 18:21:47 stevemar: nice, should be target reviews/merge to Friday anyways 18:21:51 stevemar: we did a huge amount of work to split this out into the 6 patches, but couldn’t get the last one swmaller than this 18:22:01 henrynash: i understand 18:22:06 its mostly tests 18:22:11 samueldmq: as soon as possible :) 18:22:31 ayoung: keystone/resource/core.py 319 is not mostly tests 18:22:35 and long henrynash monologues in comments 18:22:48 ayoung: that does happen, doesn't it! 18:22:51 ayoung: to wander on a cloud..... 18:23:05 :) 18:23:16 hye, I like those comments :) 18:23:17 i haven't reviewed this one yet, but i'll add it to my queue 18:23:21 very helpful for beginners specially 18:23:34 keystone/resource/core.py is the key, everything else is really support 18:23:43 henrynash: ++ 18:23:53 list_domains_from_ids is 4 lines of code (including method line itself) and 9 lines of commens 18:24:33 so someone summarize the plan. policy check at the top level and just delete all the way down? or check at each level? 18:24:46 henrynash, to strive, to seek, to find, and never to yield 18:24:52 dstanek: check at every level 18:25:19 samueldmq: perfect, thanks 18:25:23 dstanek: np 18:25:39 so nothing besides 'review it!' ? 18:25:53 samueldmq: i think so, for this patch 18:25:59 stevemar: how's shadow users? 18:26:14 samueldmq: the first patch landed 18:26:27 shadow part 1 - https://review.openstack.org/#/c/278570/ \o/ 18:26:32 but there is a bug that's being worked on 18:26:40 dstanek: link ? 18:26:48 just about to submit a patch 18:26:59 rderose: awesome 18:27:11 the second patch is here: https://review.openstack.org/#/c/279162/ 18:27:26 marekd: i'd have to look back in the keystone chat to see if it was reported...if not i was going to make one 18:27:29 even though it's WIP, i think rderose is accepting reviews? 18:27:44 stevemar: correct 18:27:49 dstanek: whats the one line description of the bug 18:27:53 would welcome reviews at this point 18:28:00 rderose: you dont have to put everything WIP :) 18:28:13 stevemar: passwords can no longer be null and that's a problem 18:28:27 dstanek: yep, major change in behaviour 18:28:28 dstanek: no problemo. 18:28:55 stevemar: 2nd line: creating with a null password should not create a password record & setting a null password should delete the existing password record 18:28:57 rderose, yeah, stop that. No more WIP 18:29:21 ayoung :) 18:29:22 ++ :) 18:29:48 just ask the infra guys to get rid of that button 18:30:10 i'm wondering if it's too late to sneak in a fix for the mapping engine, to allow just user's to be mapped, getting rid of our necessity for groups 18:30:22 heh, nah, just don't use it for something that you actually want someoneto look at 18:30:27 OK... 18:30:39 stevemar, we can map to users today I think 18:30:45 rderose, you have what you need? 18:30:47 gyee: only if they exist in SQL 18:31:03 ayoung yeah, almost done 18:31:07 rderose, ping me when you start dealing with LDAP, ok? 18:31:32 gyee: with shadow users, any federated user authenticated with keystone will have a sql entry now 18:31:36 meh, it can wait til N 18:31:49 i need diagrams and time to code it 18:31:50 stevemar, what can wait? 18:31:56 stevemar, yikes, that's going to be an adventure 18:32:06 ayoung: changing the mapping engine to not need groups 18:32:07 fix for the mapping engine? 18:32:23 stevemar: e? 18:32:25 ayoung will do 18:32:34 stevemar: you can map to a user today 18:32:35 stevemar, twould be nice. 18:32:36 stevemar, I am lost, are you propose getting rid of group mapping? 18:32:41 proposing 18:32:47 OK...moving on in 3, 18:32:52 marekd: only if they already exist in sql 18:32:59 2 18:33:03 stevemar: they now will thanks to shadow users :-) 18:33:09 1 18:33:17 stevemar: anyway, can talk later 18:33:21 marekd: yep 18:33:27 #topic Midcycle next summer 18:33:27 boom! 18:33:32 Boston? 18:33:42 there will be some security implications there 18:33:51 gyee: with Boston? :P 18:34:09 marekd, no, mapping to non-local users 18:34:09 samueldmq brought up brazil to me again yesterday 18:34:18 ayoung: what's wrong with proposal to make it in Brazil? 18:34:20 gyee: we can talk in -keystone after 18:34:21 gyee: i know, kidding 18:34:25 Brasil ++ 18:34:32 #startvote Should Adam look in to having Midcycle in Boston? Yes, No, Abstain 18:34:32 Begin voting on: Should Adam look in to having Midcycle in Boston? Valid vote options are Yes, No, Abstain. 18:34:33 Vote using '#vote OPTION'. Only your last vote counts. 18:34:50 not binding, just whether I should even bother to talk to people about feasability 18:34:51 #vote yes 18:34:54 #vote yes 18:35:01 yes, always helpful to have a backup 18:35:09 wait, are we voting for Brazil or Boston? 18:35:16 if we have reasons for not doing it here, I am okay for having it there 18:35:21 #vote yes 18:35:23 #vote yes 18:35:25 "Should Adam look in to having Midcycle in Boston?" 18:35:27 Brazil pls 18:35:36 #vote yes 18:35:37 #vote yes 18:35:37 samueldmq: my concern is getting everybody approved 18:35:42 £no 18:35:44 #no 18:35:49 #vote yes 18:35:50 #vote abstain 18:35:52 #no 18:35:57 #vote abstain 18:35:59 henrynash: your hashtag looked funny 18:36:08 henrynash: rodrigods: #no should be #vote no 18:36:11 #vote yes 18:36:14 henrynash, any reason why not? 18:36:15 #vote no 18:36:18 samueldmq, thx 18:36:21 you want it in England? 18:36:25 #vote no 18:36:26 no... 18:36:31 he's allergic to lobster I think :) 18:36:39 he wants it in san antonio again 18:36:44 In July? 18:36:45 :P 18:36:50 but I thought we were looking for bay area this time 18:36:54 I am not against it, just wanted to understand why we're changing what we've defined during midcycle? 18:36:59 this week is the neutron midcycle in rochester 18:37:02 stevemar: we're taking Boston as a backup? 18:37:16 Did not know SF was primary? 18:37:28 i think we're tossing out cities waaaaay too early 18:37:29 #showvote 18:37:29 Yes (8): gyee, dstanek, lhcheng, rderose, bknudson, marekd, tsymanczyk, stevemar 18:37:30 Abstain (2): htruta, morgan 18:37:31 No (2): rodrigods, tjcocozz_ 18:37:48 stevemar: ++ 18:37:55 it's up to whoever is ptl next cycle, and there are pros and cons to all places 18:37:57 would the bay area be insanely expensive? 18:38:16 dstanek, only if you want to rent here 18:38:22 #endvote 18:38:23 Voted on "Should Adam look in to having Midcycle in Boston?" Results are 18:38:25 Yes (8): gyee, dstanek, lhcheng, rderose, bknudson, marekd, tsymanczyk, stevemar 18:38:26 Abstain (2): htruta, morgan 18:38:27 No (2): rodrigods, tjcocozz_ 18:38:27 samueldmq: i don't think we decided on a place 18:38:34 #invalidatevote 18:38:39 samueldmq: this is by no means a decision 18:38:43 OK, I'll look in to it, with noted cavetas 18:38:48 caveats 18:38:50 dstanek, though you can have the $5 cupcakes 18:38:51 (oops hope that isn’t a real command!) 18:39:08 henrynash, http://docs.openstack.org/infra/system-config/irc.html#voting 18:39:21 dstanek: stevemar: okay, thanks for replying 18:39:23 #topic Review of Keystone Blueprints for No-Spec Requires Status 18:39:35 dstanek: stevemar: I will keep my search and come with more details 18:39:37 None listed. Any to cover? 18:39:51 nothing here at this point 18:39:52 Oh...we didn't do bugs when we did M3 18:40:07 #topic Keystone Weekly Bug Reports 18:40:17 #link http://openstack-weekly-reports.lbragstad.com/keystone-weekly-bug-report.html 18:40:20 samueldmq: i don't think i can deal with 24hrs of straight travel :-P 18:40:21 I have a blueprint for oslo.policy 18:40:35 there are a few mitaka-3 bugs https://launchpad.net/keystone/+milestone/mitaka-3 18:40:46 amakarov_away, was working on https://bugs.launchpad.net/keystone/+bug/1546562 18:40:46 Launchpad bug 1546562 in OpenStack Identity (keystone) "deleting role with implied role fails" [High,In progress] - Assigned to Alexander Makarov (amakarov) 18:40:46 which is the YAML support 18:40:52 oh good i can drop the tempusfrangit dns entry for that 18:41:27 dstanek: great's what comes after that travel :) 18:42:06 davechen removed the cascade delete. I would like to know the rationale for that 18:42:16 ayoung: the only bug i'm concerned about is 1539766 18:42:46 #link https://bugs.launchpad.net/keystone/+bug/1539766 18:42:46 Launchpad bug 1539766 in OpenStack Identity (keystone) "trust redelegation allows trustee to create a trust (with impersonation set to true) from a redelegated trust (with impersonation set to false)" [Medium,Triaged] 18:43:07 ayoung: he actually didn't remove it, we can work on it together in the afternoon, ok? 18:43:16 stevemar, Good 18:43:28 ayoung: he removed the cascade delete from where? 18:43:35 ayoung: re 1539766, i am OK with punting this to N 18:43:38 samueldmq, it was in the comment 18:43:55 its been around for a while, and no one has a patch up for it 18:43:57 stevemar, looking at the state of the review 18:44:14 ayoung: there's a fix for 1539766 ? 18:44:46 yep #link https://review.openstack.org/#/c/276474/ is listed, but maybe only partiaL? 18:44:49 yeah, not a complete fix 18:44:56 very much partial 18:45:13 i'm okay with pushing this to N, it's been around for a while 18:45:28 stevemar, we can keep working on that one. I think a fix like that is OK post M3 if it is uninvasive 18:45:48 ayoung: sure, it can be an RC fix 18:46:08 ayoung: i don't know the trust code base well enough to fix it 18:46:17 (well, fix it easily...) 18:46:32 is anybody actually using impersonation? 18:46:32 stevemar, I think oslo.policy (1) 18:46:34 [Undecided:New] Bug #1547684 in oslo.policy: "Attribute error on Token object when using domain scoped token" would have been fixed by my patch 18:46:34 bug 1547684 in oslo.policy "Attribute error on Token object when using domain scoped token" [Undecided,New] https://launchpad.net/bugs/1547684 18:46:51 https://review.openstack.org/#/c/165908/ 18:47:24 gyee, you need it for some old swift deploys, and maybe Barbican in the future 18:47:30 this is trying to use domain scoped tokens on other projects 18:47:34 there are also keystonemiddleware and keystoneclient mitaka-3 bugs 18:47:48 bknudson, the error is due to an exception, though. It should just return false 18:47:49 breton: there are? 18:48:22 oh. 18:48:29 breton, yep, but none seemed on fire....any need attention? 18:48:32 ok, looks like there isn't 18:48:39 [Undecided:New] Bug #1544839 in python-keystoneclient: "Job gate-rally-dsvm-zaqar-zaqar fails since the recent Rally patch" 18:48:39 bug 1544839 in python-keystoneclient "Job gate-rally-dsvm-zaqar-zaqar fails since the recent Rally patch" [Undecided,New] https://launchpad.net/bugs/1544839 18:48:39 [Undecided:New] Bug #1547331 in python-keystoneclient: "AuthorizationFailure: Authorization failed: Cannot authenticate without an auth_url" 18:48:40 bug 1547331 in python-keystoneclient "AuthorizationFailure: Authorization failed: Cannot authenticate without an auth_url" [Undecided,New] https://launchpad.net/bugs/1547331 18:48:53 I just wanted to get my https://review.openstack.org/#/c/280162/ in :) 18:48:58 breton: don't scare me like that 18:50:13 breton: ah that one 18:50:25 breton, added the Keystone core to that review. WOrth having a few more Keystone people familar with the Horizon & D-O-A issues 18:51:16 breton: that one makes me nervous, can do it post mitaka? 18:51:38 breton: i don't want to get into any more trouble for breaking people if it happens :\ 18:52:04 i'm just hesitant to put things in so close to rc 18:52:09 stevemar, that one looks fine 18:52:22 well, the whole change was asked by horizon people and without the patch they get nothing 18:53:36 I didn't know we never convey the truncated flag on the client side 18:53:50 gyee: yep, we don't 18:54:39 bknudson / dstanek ^ thoughts? you guys are the pythonistas 18:54:46 stevemar, off topic, Horizon is also asking for info on the domain, where it is read-only, I can submit a BP later 18:54:47 we need ListWithMeta for request_ids, too 18:55:13 bknudson: oh super 18:55:28 see https://review.openstack.org/#/c/261188/9/keystoneclient/base.py 18:55:36 line 598 18:55:42 stevemar: which review? 18:55:49 yeah, just saw that bknudson 18:56:04 dstanek: bknudson https://review.openstack.org/#/c/280162/ 18:56:08 bknudson: I tried to make my thing alike with with request_id one 18:56:26 4 minutes left 18:56:27 breton: what happened last time? we used an object? 18:56:35 any other items to bring up? 18:56:35 Collection? 18:56:36 I'll put it on my review. client is pretty useless if you can't get a truncated indicator back. 18:56:49 stevemar: yeah, a collection 18:56:51 that broke some gates/things 18:57:03 breton: why name if *Meta? i thought i was going to find a metaclass 18:57:09 stevemar: it broke because of [] == list() comparison 18:57:24 it specifically broke keysone's gate, keystoneclient tests... wheer we check that ^ 18:57:33 3 minutes 18:57:37 dstanek: because of request_id review, no other reason. I'm open to naming suggestiions. 18:57:41 but now we nuked that file anyway 18:57:47 I'll make sure it works with keystone 18:57:51 STAND! IN THE DOOR! 18:58:00 sorry. flashback 18:58:05 hah 18:58:13 breton: TruncatedList? i'll have to actually read this review though 18:58:27 breton you need more time? 18:58:28 dstanek: bknudson thanks in advance for the review 18:58:32 ayoung: no 18:58:36 i'll keep to cut a new version anyway 18:58:38 dstanek: ListWithMeta is the proposal for returning request_ids, too 18:58:38 ok 18:58:39 dstanek, how about call it a mixin like the other patch? 18:58:42 implied roles and domain roels are in 18:58:49 lets move to our home channel 18:58:49 gyee: just kill m e 18:59:00 #endmeeting