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