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