18:00:28 <dolphm> #startmeeting keystone
18:00:29 <openstack> Meeting started Tue Jan  8 18:00:28 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:32 <openstack> The meeting name has been set to 'keystone'
18:00:53 <dolphm> #topic team membership updates
18:01:10 <ayoung> http://wiki.openstack.org/Meetings/KeystoneMeeting
18:01:55 <ayoung> heckj, I think this one is yours to address....
18:01:58 <dolphm> heckj made a couple nominations for 'core' contributor status on the mailing list last week (guang-yee & henrynash)
18:02:12 <dolphm> this is definitely heckj's to address
18:02:28 <dolphm> i'd also like to throw a belated +1 for henry-nash into the ring
18:03:34 <ayoung> Well, for now, lets assume that it is a done deal.  I think we are all in agreement.
18:03:50 <gyee> \o
18:03:50 <dolphm> i guess we can leave that topic at that until heckj shares the "verdict"
18:03:54 <dolphm> gyee: /salute
18:04:14 <ayoung> yep /O
18:04:17 <dolphm> #topic High priority bugs or immediate issues
18:04:24 <dolphm> anything exciting going on? i'm not aware of anything
18:04:36 <ayoung> 0 Critical
18:04:41 <gyee> I am working on separating out authentication, token validation
18:04:45 <ayoung> 16 High importance
18:04:51 <dolphm> gyee: on the road for v3?
18:04:54 <gyee> yes
18:05:03 <gyee> I am hooking up google 2-factor auth as well
18:05:14 <gyee> with any luck, I should have a WIP review this week
18:05:14 <dolphm> gyee: awesome, joesavak and chmouel will be thrilled :) they've both been asking about auth support on v3 recently
18:05:20 <dolphm> gyee: i look forward to it
18:05:21 <ayoung> gyee, nice
18:05:28 <henrynash> indeed
18:05:35 <ayoung> on multifactor, can you spec ouyt how it will look inside the token data?
18:05:39 <dolphm> #topic multifactor
18:05:48 <ayoung> speaking of which
18:05:51 <gyee> so we have "password_credentials"
18:05:59 <gyee> that auth mechanism
18:06:10 <gyee> we are basically teeing off on the auth mechanism
18:06:20 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn
18:06:29 <gyee> so for google 2-factor, I'll have something like "google_2factor"
18:06:45 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn
18:06:48 <ayoung> gyee, so I would see it like
18:06:49 <gyee> auth mechanisms will be handler like backend drivers
18:07:08 <ayoung> auth_mechs: ["google_2factor"]
18:07:24 <ayoung> each time you authenticate token to token, you add to that list
18:07:30 <gyee> right, so for v3 , there are two auth mechanisms by default
18:07:36 <gyee> password_credentials and token
18:07:45 <ayoung> maybe we can just call that field "factors"?
18:07:55 <ayoung> probabl auth_factors
18:08:10 <egallen> Design specs must be independent of the factor
18:08:14 * heckj runs in and runs out - will promote the +1'd folks to core this afternoon & announce in release meeting & mailing list (congrats gyee & henrynash!)
18:08:31 <dolphm> factors is slightly more complicated than that, in that 2 "somethings you know" are still just 1 "factor" (something you know)
18:08:32 <ayoung> heckj, you have something else you want to add?
18:08:45 <ayoung> dolphm, so the idea was we list the factors in the token
18:08:49 <dolphm> so ['password', 'mothers_maiden_name'] is 1 factor auth
18:08:49 <ayoung> and then RBAC uses
18:08:53 <ayoung> er, policy
18:09:03 <ayoung> uses the factors to decide "This token is good enough"
18:09:22 <dolphm> ['password', 'mothers_maiden_name', 'rsa_token'] == 2 factor auth
18:09:31 <gyee> google 2factor supports both sequence-based hash or time-based hash
18:09:33 <dwchadwick> there is a better way than this. Its called level of assurance (LoA) if anyoone has heard of it
18:09:39 <gyee> very straight forward
18:09:51 <ayoung> dwchadwick, yes.  I think that is what we are headed toward
18:09:52 <gyee> I tested it with my android phone, pretty easy to use
18:09:54 <dwchadwick> There is a NIST standard on it, and an ISO standard as well
18:10:06 <ayoung> dwchadwick, the thing is, it needs to be enforced by the policy engine
18:10:16 <dwchadwick> We have already included this in our federation work
18:10:40 <dwchadwick> Exactly. That is what LOA is for. For over 5 years our PERMIS policy engine has support LOA
18:10:42 <ayoung> dwchadwick, have you specified how it modifieds the data encapsulated in the signed token document?
18:11:02 <gyee> for multi-factor, we'll have something like "transitional" tokens
18:11:08 <dwchadwick> LOA is an attribute assigned to the user, just like any other identity attribute
18:11:22 <dwchadwick> so that the PDP makes decisions based on all the attributes
18:11:28 <ayoung> dwchadwick, is that the name of the attribute "LOA"?
18:11:30 <gyee> transitional tokens are like unscoped tokens except you can't trade them in for a scope token
18:11:36 <ayoung> I would like to avoid TLAs
18:11:42 <dwchadwick> Yes LOA (for level of assurance)
18:11:49 <dwchadwick> There are two ways you can handle it.
18:11:56 <dwchadwick> 1. As a subject attribute or
18:12:03 <dwchadwick> 2. As an environmental attribute
18:12:29 <ayoung> gyee, why not trade them in?
18:12:35 <dolphm> gyee: would it make more sense to simply add an extra factor to *any* valid token you have?
18:12:35 <dwchadwick> It does not really matter as long as the policy writer and the authn engine in Keystone agree and put the attribute in the right place
18:13:17 <dolphm> gyee: what's the problem with trading in a "transitional" token for one with authz?
18:13:40 <gyee> well, auth policies is a different issue
18:13:58 <ayoung> so  in the auth dictionary of the token we have a field factors.  It will have an array.  I will write up the values that go in there based on existing mechanisms.  Any additional mechanisms will get reviewed when they get submitted as patch review
18:14:00 <dwchadwick> gyee - please done use auth
18:14:00 <ayoung> s
18:14:02 <gyee> for 2factor, transitional token is an incomplete token
18:14:10 <gyee> like a half token
18:14:11 <dwchadwick> use either authn or authz then it is clear what you mean
18:14:20 <ayoung> dwchadwick, I'll post a sample JSON doc.  1 sec
18:14:55 <gyee> today, you can trade in an unscoped token for a scoped token
18:14:59 <ayoung> gyee, instead, it will be a token that would not pass the policy check on some servers.
18:15:23 <ayoung> so if you auth with just uid/pw, you could trade that for a scoped token, but it still wouldn't make it pass the policy check.
18:15:26 <gyee> transitional token just holds the state of auth
18:15:37 <dwchadwick> If tokens are created by keystone and validated by keystone why does it matter to any other service what they contain
18:15:44 <ayoung> gyee, so my point is that we won't have explicit transitional tokens
18:16:01 <ayoung> dwchadwick, because it is up to the other services to determine the LOA they require
18:16:06 <gyee> right, I am thinking about inventing one :)
18:16:11 <ayoung> Keystone does not enforce policy
18:16:17 <ayoung> gyee, don't
18:16:21 <ayoung> gyee, we don't need them
18:16:35 <dwchadwick> but the token contains the loa buried secretly in it, and keystone tells the service what the loa is whe n the service asks keystone to validate the token
18:16:40 <gyee> so for auths that require multiple roundtrips, what token do we issue?
18:16:58 <dwchadwick> so the LOA needs to be passed back in keystone's response but that is all you need to define to the outside world
18:17:09 <dolphm> dwchadwick: why does it need to be buried / a secret?
18:17:11 <ayoung> gyee, a token that specifies what authorization mechanism was used to generate it
18:17:37 <dwchadwick> dolph: because the format of the token is opaque to the service
18:17:43 <gyee> ayoung, authentication mechanism?
18:17:57 <dwchadwick> the service is given a blob by the user and passes the blob to keystone for validation
18:18:25 <dwchadwick> In this way keystone can change the blob format and the service is unaffected by it
18:18:33 <dolphm> dwchadwick: ah, didn't realize that's all you meant
18:18:41 <ayoung> gyee, OK,  say I need 2 factors:  uid/pw and  PKI  for example.
18:18:54 <ayoung> First I auth with uid/pw and get a token.  Then I resubmit that token with PKI
18:19:13 <gyee> ayoung, that's two "complete" auths
18:19:14 <ayoung> now I have a token with auth{ factors:[pki,pw]
18:19:17 <dwchadwick> ayoung. In your authz policy you say "in order to access this resource you need a role of X and an Loa of 43
18:19:23 <dolphm> ayoung: that's still 1 factor auth -- both are something you know
18:19:33 <dwchadwick> 43 should be 3
18:19:37 <ayoung> dolphm, please stop confusing the issue with facts.
18:19:45 <gyee> dude
18:19:58 <gyee> say we have a challenge-response auth mechanism
18:20:07 <gyee> which require multiple roundtrips
18:20:17 <gyee> how do we issue something that holds the transitional state?
18:20:29 <dwchadwick> you guys need to separate out authz from auth. LOA is the perfect mechanism for this
18:20:36 <ayoung> gyee, that is outside of Keystone
18:20:54 <gyee> well, we have to issue/return something
18:20:54 <ayoung> dwchadwick,  authZ from authN?
18:21:00 <dwchadwick> yes
18:21:13 <dolphm> gyee: can you start a mailing list discussion on this topic with the direction that you're headed? obviously there's a lot to be discussed that we won't be able to cover today :)
18:21:20 <ayoung> dolphm, will do.
18:21:24 <gyee> yes sir
18:21:35 <dolphm> meeting agenda is crazy long today
18:21:40 <dolphm> #topic mapping
18:21:43 <dolphm> ayoung: ^?
18:21:47 <ayoung> dolphm, what I am describing is the end result of the discussion from the summit.  I'll clean up the spec.
18:21:59 <ayoung> dolphm, I assume you mean mapping for LDAP and groups?
18:22:13 <dwchadwick> we have posted one new spec for mapping and revised the existing spec
18:22:14 <ayoung> as the Kent folk also have mapping stuff to discuss
18:22:15 <dolphm> "mapping (groups? attributes? ldap? ?? ayoung)" full topic on the agenda
18:22:29 <ayoung> OK.  one thing at a time
18:22:32 <ayoung> first up is groups
18:22:52 <ayoung> henrynash' sreview has been approved and will merge once Jenkin's issues are sorted
18:22:58 <gyee> w00t!
18:23:00 <henrynash> it's merged
18:23:06 <ayoung> https://review.openstack.org/#/c/18097/
18:23:24 <henrynash> gyee: indeed!
18:23:24 <ayoung> that has a SQL backend, but no LDAP.  henrynash and I will work through that offline
18:23:46 <henrynash> ayoung: yep, have some other IBM folks I can bring in to help on that too
18:24:06 <ayoung> henrynash, cool.  Anything else that we need to discuss in this forum?
18:24:18 <dwchadwick> if you make the group change to controllers shouldnt it be independent of the backend
18:24:20 <henrynash> not on this one
18:24:39 <ayoung> dwchadwick this is where  the group information is stored
18:25:16 <dwchadwick> I know, but when we are producing the attribute mapping code we are now doing it in the controllers
18:25:27 <ayoung> dwchadwick, OK,  care to talk through your updated mapping spec?
18:25:33 <dwchadwick> so that it does not matter what backend you have (or so Kristy informs me)
18:25:41 <dwchadwick> Yes can do
18:25:52 <ayoung> dwchadwick, right, and for your code, that is the right place to do it, but even your code persists mapping, it just does it in a separate backend
18:25:57 <ksiu> dwchadwick, it still needs a backend interface
18:26:05 <henrynash> dwchadwick….but you need to store it somewhere (or at least someone needs to)…
18:26:18 <dwchadwick> To the spec changes
18:26:31 <ayoung> ksiu, you are creating a new backend module called "mapping" right?
18:26:31 <dwchadwick> The original spec assumed that the keystone admin was in charge of everything
18:26:44 <ksiu> i think I may have created some confusion here, I may have mispoke, I was discussing moving some functionality
18:26:47 <dwchadwick> also the APIs were too low level for Henry to use
18:26:54 <henrynash> dwchadwick…and need to decide which backends you need to support
18:26:56 <dolphm> dwchadwick: the controllers consume an interface to a backend, but it doesn't matter what backend the user has configured (all backends should implement the interface equally); the backend driver still need to support whatever calls you need to make, such as "persist_new_mapping"
18:26:56 <dwchadwick> So the new spec does two things
18:27:12 <dwchadwick> a) provides a mechanism for distributed administration of mappings
18:27:29 <dwchadwick> b) provides a high level API for these admins to use which makes attribute mapping easy
18:27:51 <ayoung> dwchadwick, so a) sounds like a general purpose problem solver
18:28:04 <dolphm> dwchadwick: (a) is dependent on (b) i assume?
18:28:07 <henrynash> dwchadwick/ksiu: do we have a proposal on the formal api doc on that?
18:28:07 <ayoung> can you talk through it in a little more detail
18:28:11 <dwchadwick> dolph: I will leave you and Kristy to deal with these "implementation" issues if you dont mind
18:28:19 <dolphm> dwchadwick: no problem
18:28:21 <dwchadwick> No
18:28:38 <ayoung> OK, moving on then..
18:28:40 <ayoung> heh
18:28:44 <dolphm> next topic?
18:28:59 <dolphm> #topic register modules
18:29:08 <dolphm> i'm not really sure what this is -- anyone?
18:29:08 <dwchadwick> it would be posssible for the keystone admin to distribute out the work and let the admins use the low level APIs, but it would be inconvenient to them
18:29:33 <henrynash> dolphm: nope
18:29:36 <dwchadwick> henry: on what
18:29:52 <ayoung> dolphm, ah, let me address
18:30:05 <henrynash> (on knowing what register modules is)
18:30:09 <gyee> ayoung, that's the lazy loading stuff you working on?
18:30:15 <ayoung> gyee, yes
18:30:17 <gyee> ah
18:30:18 <ayoung> here is the issue
18:30:25 <ayoung> controllers need backends
18:30:37 <ayoung> recently, we have made decent strides in cleaning this up
18:30:41 <ayoung> thanks dolphm
18:30:50 <ayoung> but there is still a little ugliness
18:31:03 <dolphm> ayoung: modules == concrete classes?
18:31:14 <ayoung> In order for a backend to fulfill a dependency it needs to have been created already
18:31:31 <gyee> ayoung, any reason you can't use keystone.openstack.common.importutils?
18:31:34 <ayoung> dolphm, well, I would say modules = identity, trusts, tokens...
18:31:39 <ayoung> gyee, hold on
18:31:56 <ayoung> there are 3 pieces in play, before we talk solutions
18:32:03 <dolphm> gyee: i'm not sure that 'modules' == 'python modules'
18:32:06 <ayoung> 1) a class has to say what it needs
18:32:32 <ayoung> 2) the web server etc needs to specify what class fills what dependency
18:32:40 <ayoung> and 3) that class needs to be loaded
18:32:57 <ayoung> all that has to happen before we can resolve a dependency
18:33:19 <ayoung> right now, we have this  managers() mechanism from termie's efforts
18:33:33 <ayoung> it allows us to swap out the implementation based on the configu file
18:33:44 <ayoung> which is basically what I want to be able to do, just in a more general way
18:34:27 <ayoung> So I'd like to drop "managers" and instead have code that iterates through the Drivers list in config and regsters which classes are used to resolve those depenedencies
18:34:36 <ayoung> This would be built on top of my strings->classes work
18:34:51 <ayoung> #link https://review.openstack.org/#/c/18542/
18:35:33 <dolphm> ayoung: that would certainly work, but where would you put code that managers currently implement? (e.g. exception handling)
18:35:35 <ayoung> One thing it would clean up is that we wouldn't need to have code to explicitly create all of the Managers early on
18:35:57 <ayoung> dolphm, let me post the link
18:36:22 <ayoung> https://github.com/openstack/keystone/blob/master/keystone/common/manager.py
18:36:25 <ayoung> That is all they do
18:36:42 <ayoung> dolphm, there is also some real ugliness there
18:36:57 <ayoung> in that we make calls with context used as the slef pointer.
18:37:00 <ayoung> self
18:37:02 <dolphm> ayoung: classes that extend keystone.common.manager.Manager have implementation details
18:37:26 <ayoung> dolphm, Identity, for example
18:37:44 <ayoung> https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L51
18:38:19 <dolphm> ayoung: the identity manager is relatively barren compared to https://github.com/openstack/keystone/blob/master/keystone/policy/core.py#L29
18:38:22 <ayoung> so tokens is in here https://github.com/openstack/keystone/blob/master/keystone/token/core.py#L70
18:38:38 <ayoung> And that code can easiler go into the Driver at the class level
18:38:41 <ayoung> let me look
18:38:54 <dolphm> ayoung: then it must be replicated into every driver?
18:39:07 <ayoung> dolphm, no
18:39:25 <ayoung> Drivers are treated as abstract base classes, but they don't have to be pure abstract
18:39:39 <ayoung> we'd need to deconflict names, like get_policy
18:40:18 <dolphm> ayoung: i see where you're going, but i think the rest of this conversation would be best suited in the context of the code review?
18:40:30 <dolphm> ayoung: i think everyone else is falling asleep
18:40:40 <gyee> I am still awake, barely :)
18:40:59 <ayoung> dolphm, fair enough. I just wanted people aware of where I was going with this, and why.  Much easier up front.
18:41:06 <dolphm> ayoung: cool
18:41:08 <ayoung> We can move on
18:41:10 <gyee> ayoung +1
18:41:15 <dolphm> #topic Test coverage
18:41:31 <dolphm> ayoung: i assume you've been tracking our coverage?
18:41:35 <dolphm> ayoung: has it improved?
18:41:37 <ayoung> Have not looked at it
18:41:53 <dolphm> (why was this on the agenda then?)
18:41:57 <ayoung> dolphm, let me regen the stats and hit this at the end of the meeting
18:42:10 <ayoung> dolphm, because we said we were going to review
18:42:28 <dolphm> ayoung: cool, we need to get jenkins tracking our coverage again (it used to chart it for every commit)
18:42:52 <dolphm> i think it got killed because it started recording 0% coverage all the time
18:42:59 <dolphm> ayoung: ah
18:43:11 <dolphm> #link Discussion on proposed api changes for domain role grants
18:43:15 <dolphm> #topic Discussion on proposed api changes for domain role grants
18:43:22 <dolphm> #link https://review.openstack.org/#/c/18706/
18:43:28 <henrynash> hopefully can make this quick…Dolph - I changed the bp to just be the re-specifation of what it meant to assign a role to a domain
18:43:51 <henrynash> ..i.e. it means just to the container (not all the projects within it)
18:44:11 <dolphm> so, for everyone else... to grant a user a role on all projects in a domain: you'll have to get the list of projects in the domain, and then make a grant call for each project you get back
18:44:30 <dolphm> it's a bit more chatty, but lets us distinguish between grants on the domain itself and grants on the contents of the domain
18:44:33 <dolphm> any objections?
18:44:41 <gyee> wait
18:44:49 <dolphm> i assume only keystone will consume domain-grants
18:44:55 <henrynash> for now yes
18:45:02 <gyee> so what does granting a role to a domain mean?
18:45:16 <dwchadwick> good question
18:45:18 <dolphm> gyee: absolutely nothing to other services
18:45:30 <henrynash> e.g. give a user permission to manage user and drops for a given domain
18:45:43 <dolphm> gyee: but to keystone, it means you have a role on the container, so you could (for example) create projects in that domain
18:45:50 <henrynash> i.e. the keystone policy engine will process this
18:46:02 <gyee> oh, so its a domain admin role then?
18:46:06 <ayoung> henrynash, hrm.  Let me process that.  Not sure I like it, as it makes the implementation tricky.  I'm not saying "No"  just lets discuss in a couple days.
18:46:10 <dolphm> gyee: yes
18:46:12 <dwchadwick> this is not granting a role to a domain. this is granting a role permission to perform ops on the domain
18:46:21 <dolphm> gyee: could be more granular as well
18:46:25 <henrynash> dwchadwick: yes
18:46:48 <dwchadwick> so it would help to be more precise
18:46:51 <henrynash> ayoung: sure
18:47:13 <dolphm> dwchadwick: "not granting a role to [the contents of] a domain" yes; however, i imagine that if you have some sort of admin role on the domain, nothing is stopping you from granting yourself roles on all the of contents of the domain
18:47:52 <gyee> dolphm, I am fine with this
18:47:57 <dolphm> gyee: cool
18:47:58 <dwchadwick> correct. but this is still granting permissions to a role, isnt it? they are just diferent permissions
18:48:08 <dolphm> gyee: checkout the linked review above if you have a chance
18:48:14 <gyee> ok
18:48:19 <ayoung> do we need domain level roles at all?  Don't groups support that use case better?
18:48:33 <dwchadwick> groups dont have permissions
18:48:55 <dwchadwick> groups map into roles and roles have permissions
18:49:02 <gyee> ayoung, role definitions are global right now, you saying domain-level role definitions?
18:49:24 <ayoung> gyee, OK, let me be clearer
18:49:34 <ayoung> do we need domain specific role grants?
18:49:49 <dolphm> ayoung: i think they're sort of orthogonal concepts -- domains own users and projects, groups collect subsets of users from any domain as an administrative shortcut
18:49:53 <dwchadwick> I would say yes
18:50:09 <dwchadwick> since domains are autonomous units arent they? so they should have different permissions
18:50:13 <ayoung> gyee, I can see where two domains might have different names for  their roles.
18:50:16 <henrynash> ayoung: how would I allow one user to only, day, manage the crud for users and groups in one particular domain, but they not have any project access
18:50:24 <henrynash> (a very common enterprise job)
18:50:36 <dolphm> ayoung: when i wrote the spec for domain role grants, i failed to distinguish between having a role on the domain and having a role on the contents of the domain; this fixes that
18:50:54 <gyee> ayoung, I would love to have role definitions own by domains
18:51:24 <gyee> meaning you can only grant domain-roles to users for projects within the domain only
18:51:28 <dwchadwick> I thought we agreed months ago that roles could be both local and global
18:51:52 <ayoung> dolphm, henrynash right, I can see the need to be able to administer the domain,  but why would I want to be able to use gratns to grant a role to au ser for all projects in that domain.
18:52:06 <ayoung> That, to me, is what groups are for.
18:52:21 <henrynash> ayoung: that's way we took out
18:52:38 <ayoung> henrynash, then there should be no need for a flag
18:52:53 <ayoung> the role is never applied to the enclosed projects
18:52:54 <henrynash> ayoung: it's been removed, see the commit comment
18:53:14 <ayoung> henrynash, ah, I was looking at the blueprint.  We are in violent agreement
18:53:15 <henrynash> ayoung: I should go update the bp as well, sorry
18:53:25 <henrynash> ayoung: +2
18:53:40 <dolphm> yay
18:53:44 <gyee> nice
18:53:50 <dolphm> #topic Discussion on proposed api changes for domain token scoping
18:53:55 <dolphm> #link https://review.openstack.org/#/c/18770/
18:54:27 <henrynash> this is kind of the partner in crime….so you can get a token that lets you do the admin role
18:55:02 <dolphm> so, this ties into the previous conversation, and other services wouldn't support these tokens, as there's no project-level authorization
18:55:33 <ayoung> dolphm, that may not be true.  It should not be up to Keystone to enforce
18:55:33 <henrynash> dolphm: yes..one day I can imagine cases when the might (e.g. images that are common to a domain)
18:55:43 <ayoung> henrynash, zacly
18:56:15 <henrynash> but they can do that in their own time…this lays the foundations
18:56:51 <ayoung> henrynash, so the follow on work is "scope a token to a set of endpoints."
18:57:08 <ayoung> Feel free to knock that out as well!
18:57:24 <henrynash> ayoung: I'll certainly take a look!
18:57:43 <ayoung> henrynash, cool, we can talk about that offline
18:57:48 <dolphm> henrynash: if we implement this in auth_token middleware, we need to be very careful about what is exposed as DOMIAN_ID / DOMAIN_NAME to the underlying service (as we have both the user's owning domain and potentially the token's domain-scoped authz, which may not reflect the same domain)
18:57:56 <ayoung> 3 minutes remaining
18:58:21 <ayoung> we can skip Dependency injectsion
18:58:24 <henrynash> dolphm: ok
18:58:24 <ayoung> already covered it
18:58:25 <dolphm> USER_DOMAIN_ID / USER_DOMAIN_NAME (user's owning domain) + DOMAIN_ID / DOMAIN_NAME (authz scope)
18:58:43 <dolphm> ayoung: k; i'll push the rest of the topic to next week
18:58:55 <gyee> good idea, need time to absorb this
18:58:58 <ayoung> dolphm, migration, for the last minute?
18:58:59 <dolphm> topics*
18:59:03 <ayoung> "Default" domain migration (dolphm)
18:59:20 <dolphm> ayoung: i don't have a code review up for that yet, so i'll push that as well
18:59:23 <ayoung> Cool.
18:59:39 <ayoung> If anyone is willing to talk SQL, lets to that in #openstack-dev after this
18:59:46 <dolphm> #topic open discussion
18:59:58 <dolphm> super brief, we have like 10 seconds on my clock ;)
18:59:59 <gyee> can somebody review my memcache protection changes?
19:00:02 <ayoung> Summit is in Portland this year
19:00:04 <dolphm> gyee: link?
19:00:24 <gyee> dolphm: https://review.openstack.org/#/c/18909/
19:00:27 <gyee> thanks
19:00:32 <dolphm> always wanted to go to portland (i've been to vancouver, which was fantastic)
19:00:38 <dolphm> #link https://review.openstack.org/#/c/18909/
19:00:42 <ayoung> gyee, please add the core devs to the list of reviewes for important changes
19:00:50 <ayoung> list of reviewers
19:00:52 <gyee> ayoung, will do
19:01:00 <dolphm> i get notified either way :)
19:01:07 <ayoung> times up.  we all revert to mice and pumpkins
19:01:10 <dolphm> hence my review queue moves slowly
19:01:23 <dolphm> hack responsibly, everyone
19:01:25 <dolphm> #endmeeting