18:02:01 <dolphm> #startmeeting keystone
18:02:02 <openstack> Meeting started Tue Jun  3 18:02:01 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:05 <openstack> The meeting name has been set to 'keystone'
18:02:11 <dolphm> #topic keystone-specs
18:02:32 <dolphm> #info Add openstack/keystone-specs to your Watched Projects in gerrit, and start reviewing!
18:02:45 <topol> o/
18:02:57 <morganfainberg> Please review! Lets get specs approved!
18:03:03 <bknudson> so I think we're getting close to J1
18:03:16 <bknudson> should we be getting things in for J1 rather than looking at specs for j2?
18:03:16 <morganfainberg> bknudson, June 12
18:03:27 <dolphm> #info All featurey/blueprinty/wishlisty changes will require an approved keystone-specs doc after juno-1 ends (June 12)
18:03:38 <bknudson> I don't know what we want to get into j1
18:03:44 <bknudson> probably compressed tokens
18:03:48 <morganfainberg> bknudson, if things are slated for J1 those are priority *cough* compressed tokens
18:03:57 <topol> love keystone-specs.  love the structure and organization
18:04:08 <dolphm> #topic Juno-1 (June 12)
18:04:11 <henrynash> topol: ++
18:04:12 <dolphm> #link https://launchpad.net/keystone/+milestone/juno-1
18:04:17 <morganfainberg> bknudson, otherwise, it should be focused on specs so once J2 opens we can get moving.
18:04:30 <henrynash> bknudson: multi-domain uuids
18:04:34 <dolphm> our juno-1 target list is fairly short, but compressed tokens is certainly at the top of the list
18:04:38 <bknudson> ah, also "Document v2 to v3 API migration strategy"
18:04:41 <ayoung> compressed tokens and revocation events are the two things left over from Icehouse.  But Revocation events are client only
18:04:45 <dolphm> i'd like to see them be the default in devstack before we check that box as done
18:05:16 <morganfainberg> dolphm, we need to ensure everyone has updated minimum reqs to 0.9.0 of KSC
18:05:22 <stevemar> dolphm, compressed tokens as default?
18:05:23 <morganfainberg> dolphm, but it's doable
18:05:25 <dolphm> bknudson: i consider this to be a first step toward having a migration strategy (mostly the last section) https://review.openstack.org/#/c/96242/
18:05:25 <ayoung> dolphm, devstack default to compressed tokens?
18:05:29 <dolphm> stevemar: yes
18:05:31 <dolphm> morganfainberg: ++
18:05:33 <dolphm> ayoung: yes
18:05:36 <stevemar> dolphm, is there a patch?
18:05:43 <ayoung> stevemar, Proof of concept only
18:05:50 <ayoung> needs to get through unit tests etc
18:05:54 <stevemar> i mean a devstack patch
18:05:59 <ayoung> #link https://review.openstack.org/#/c/91145/
18:06:09 <dolphm> stevemar: we don't even expose them in keystone yet^
18:06:17 <morganfainberg> stevemar once it passes out unit tests we can open the devstack review
18:06:19 <bknudson> the current poc makes compressed tokens the default provider
18:06:29 <ayoung> bknudson, true
18:06:30 <stevemar> bknudson, thanks
18:06:36 <ayoung> bknudson, I can remove that.
18:06:51 <morganfainberg> ayoung, bknudson, i'm fine with that but i think we should make the default switch explicit if we're changing that.
18:07:09 <ayoung> morganfainberg, nah, lets get it in, then make things use it buy default
18:07:14 <ayoung> by
18:07:16 <morganfainberg> and i think keystone should switch the default, not have a devstack "option"
18:07:26 <ayoung> morganfainberg, two patches, then?
18:07:27 <morganfainberg> ayoung, ++ we change not devstack changing.
18:07:35 <bknudson> devstack already has an option to set the token provider
18:07:43 <bknudson> so you can switch to uuid easily
18:07:47 <morganfainberg> ayoung, yeah, make sure it works, and then we work on flipping the switch.
18:07:56 <topol> morganfainberg I think devstack options are very helpful. Changing devstack config without them is a pain
18:08:04 <bknudson> KEYSTONE_TOKEN_FORMAT=UUID
18:08:13 <stevemar> is someone on the devstack team aware of the impending change?
18:08:16 <morganfainberg> ayoung, in case we need to juggle things around in other projects.  we then aren't holding up support of compressed tokens because some project X is balking at it
18:08:21 <morganfainberg> ayoung, for some reasons
18:08:25 <morganfainberg> bknudson, ++
18:08:27 <ayoung> lets get the PKIZ provider merged non-default, then people can test with devstack, and we can have the discussion about what to do after that
18:08:38 <bknudson> ayoung: works for me.
18:08:39 <topol> devstack release on its own shcedule. is there really a dependency here?
18:08:47 <morganfainberg> bknudson, i'm sorry i meant in devstack-gate, different thant devstack
18:08:50 <dolphm> devstack releases?
18:09:14 <topol> oh, he meant the devstack-gate???\
18:09:17 <morganfainberg> yeah.
18:09:30 <bknudson> morganfainberg: a new d-g job?
18:09:32 <topol> :-)
18:09:52 <bknudson> btw, devstack does have stable/ releases, so I think they follow the regular openstack releases
18:10:09 <bknudson> stable branches
18:10:24 <dolphm> yeah... it's a branch, not so much a release
18:10:27 <bknudson> they don't release it, like as a pip download
18:10:46 <morganfainberg> bknudson, no, just don't want to have to add options to dsg project to support flipping things around like this up front - argue if we need it as part of the matrix stuff after it "works" and we make it default on
18:10:57 <dolphm> anyway, is there anything else to land in j1? this is the last reasonable chance to get attention on something new
18:11:11 <ayoung> dolphm, yeah...
18:11:15 <ayoung> the sql migratiosn for extensions
18:11:17 <morganfainberg> topol, devstack-gate is the QA project that controls how tempest nodes etc (devstack) nodes are configured in check/gate
18:11:23 <henrynash> dolphm: I’m tyring to land the multi-domain UUIDs
18:11:23 <dolphm> ayoung: link?
18:11:27 <bknudson> might be nice to get https://review.openstack.org/#/c/70630/ in
18:11:30 <ayoung> #link https://review.openstack.org/#/c/96326/
18:11:38 <dolphm> ayoung: henrynash: target the bp's to j1
18:11:48 <henrynash> dolphm: ahh. oops
18:12:06 <morganfainberg> bknudson, ++ on the templated catalog v3
18:12:07 <ayoung> dolphm, I wrote that as a POC, but  there is no BP  or anything...it was a response to people complaining about the migrations not being run
18:12:10 <stevemar> ++ templated
18:12:15 <ayoung> I guess there is no reason it can't wait til J2
18:12:25 <morganfainberg> ayoung, lets push that to j2.
18:12:33 <morganfainberg> no need to "rush" that.
18:12:37 <stevemar> morganfainberg, ++
18:12:48 <ayoung> morganfainberg, it does have a bug report associate with it, which is how I was addressing it
18:13:00 <ayoung> I don't know if it calls for a BP,  dolphm 's call
18:13:01 <dolphm> bknudson: ++
18:13:09 <dolphm> ayoung: bug is fine for that i think
18:13:16 <ayoung> dolphm, https://bugs.launchpad.net/keystone/+bug/1324260
18:13:17 <uvirtbot> Launchpad bug 1324260 in keystone "Always migrate the the db for extensions instead of conditionally" [Medium,In progress]
18:13:18 <dolphm> ayoung: i assumed you were referring to a bp
18:13:19 <morganfainberg> ayoung, i would say it's a bug. it's inconsistent schemas not massive overhaul
18:13:45 <ayoung> so the general rule I've been going with is "if it is a default extension, it should be migrated by default"
18:13:59 <ayoung> but we've not had any default extensions that require migrations until fairly recently
18:14:18 <ayoung> new schemas for new extensions do not get migrated by default.
18:14:22 <ayoung> Hence the explicit list
18:14:50 <bknudson> ec2_extension_v3 s3_extension simple_cert_extension
18:14:54 <bknudson> are the default extensions
18:15:18 <ayoung> bknudson, and those don't have migrations
18:15:24 <bknudson> right
18:15:26 <morganfainberg> from a deployment standpoint, i just want to voice how crappy it is that to "enable" an extension i need to explicitly migrate it
18:15:35 <ayoung> but now oauth, endpoint_filter are promoted
18:15:38 <morganfainberg> erm explicitly do a DB migration
18:15:40 <gyee_> "default extensions" doesn't sound right, if they are enabled by default they are not extensions :)
18:16:03 <ayoung> gyee_, yes they are
18:16:10 <ayoung> gyee_, they are not part of the core API
18:16:20 <ayoung> they are endpoints enabled in keystone by default
18:16:26 <gyee_> ayoung, I mean if they are enabled by default, they need to be core
18:16:29 <morganfainberg> ayoung, and hence the whole OpenStack arguemnt on why extensions suck (or not suck)
18:16:30 <gyee_> simple as that
18:16:31 <ayoung> so for Juno
18:16:33 <ayoung> ['endpoint_filter', 'federation', 'oauth1', 'revoke']
18:16:40 <dolphm> bknudson: and trusts is so default it's hardcoded
18:16:57 <ayoung> dolphm, trusts is not even in contrib
18:17:09 <bknudson> dolphm: trusts isn't an extension by some definitions
18:17:14 <ayoung> and it's migrations are part of common repo
18:17:24 <dolphm> bknudson: it's implementation is not an extension, it is defined as an API extension
18:17:42 <bknudson> I'll have to make sure I handle it correctly in the v3 extensions advertisment
18:17:48 <ayoung> making trusts an extension was a last minute decision.  It would have been done cleaner if it wasn't suggested 2 weeks after code freeze
18:18:01 <ayoung> but that horse is dead
18:18:24 <morganfainberg> ayoung, there are ways to revite that horse... but not in scope of this conversation
18:18:28 <morganfainberg> revive*
18:18:38 <gyee_> give it water
18:19:02 <ayoung> morganfainberg, I'd be OK with that:  we really need to integrate all of the delegation mechanisms into one core api
18:19:29 <stevemar> ayoung, yeah, mark that for Kilo
18:19:30 <morganfainberg> ayoung, i totally agree
18:19:38 * ayoung whistles
18:19:40 <henrynash> kilo?
18:19:47 <morganfainberg> henrynash, K release
18:19:51 <ayoung> Oh, one other patch I want for J1
18:19:52 <morganfainberg> henrynash, as of yet unnamed
18:19:54 <stevemar> K release
18:19:58 <henrynash> ah, just checking
18:20:01 <ayoung> https://review.openstack.org/#/c/95989/
18:20:08 <ayoung> #link https://review.openstack.org/#/c/95989/
18:20:14 <ayoung> Kerberos as an extension name:
18:20:26 <ayoung> er method name
18:20:44 <dolphm> let's move on since we're way out of scope for j1 talk :)
18:20:50 <dolphm> #topic Juno hackathon
18:20:51 <ayoung> it means that we have a consistant way to say "this is Kerberos"  whether we go with "external" or Jose's approach
18:20:57 <dolphm> #link http://dolphm.com/openstack-keystone-hackathon-for-juno
18:21:10 <ayoung> dolphm, is ^^ OK as is?
18:21:16 <morganfainberg> woo geekdom!
18:21:17 <dolphm> I finally got acknowledgement on the location: 112 East Pecan, San Antonio, Texas 78205
18:21:26 <ayoung> modulo jamielennox 's comments?
18:21:26 <lbragstad> so for sure at Geekdom
18:21:31 <dolphm> it's middle of downtown in a Geekdom event space
18:21:33 * morganfainberg needs to go get approval for this trip now.
18:21:39 <dolphm> so, book any hotel downtown!
18:21:50 <stevemar> oh right, do we have hard dates?
18:21:56 <gyee_> morgafainberg, shouldn't be a problem for you :)
18:21:59 <stevemar> I was looking at hotels last night
18:22:03 <ayoung> which is the preferred Hotel?
18:22:05 <dolphm> stevemar: July 9-11
18:22:07 <henrynash> geeks road trip…excellent!
18:22:45 <lbragstad> #link https://www.google.com/maps/search/hotels+near+Geekdom+san+antonio+tx/@29.4285235,-98.4919432,17z/data=!3m1!4b1
18:22:50 <stevemar> I think Holiday Inn San Antonio Riverwalk 217 N St Mary's St is nearby, and affordable
18:23:37 <topol> what was wrong with valencia?
18:23:39 <dolphm> i suggested Hotel Valencia http://www.hotelvalencia-riverwalk.com/ only because rackspace has a preferred rate there that everyone *should* be able to take advantage of; it's also about 2 blocks from geekdom
18:23:40 <stevemar> henrynash, bknudson lbragstad topol - the one i mention is in our policy
18:23:49 <morganfainberg> gyee_, waiting on corp CC to arrive and then need to poke some people to get the sign off, but i'm sure it'll be easy
18:23:52 <stevemar> topol, we're not at the "Mall" this time around
18:23:59 <henrynash> stevemar: the man’s way ahead of me
18:24:07 <dolphm> i'm told you just have to call to make the reservation, and tell them you're in town to visit rackspace
18:24:11 <topol> stevemar we can get an exception if valencia is optimal. yes I know we are at geekdom
18:24:29 <topol> but if that works for everyone and we dont need an exception thats fine too
18:25:14 <topol> I'll get a rental car so we have one if we need it
18:25:48 <morganfainberg> topol, neverlost!
18:25:54 * morganfainberg ducks
18:26:01 <bknudson> topol: you might need a rental bus for all of us
18:26:05 <topol> next time...
18:26:10 <topol> stevemar can get one too
18:26:12 <lbragstad> conversion van!
18:26:22 <morganfainberg> lbragstad, limo?
18:26:32 <dolphm> thankfully downtown is full of one way streets, so it's impossible to get lost
18:26:36 <topol> but lets make sure we are in walking distance
18:27:17 <topol> was the holiday in walking distance?
18:27:20 <dolphm> lbragstad: careful with that google search-- geekdom has two locations downtown now
18:27:35 <dolphm> lbragstad: one is their co-working space and the other is their event space
18:27:45 <topol> if not let's do valencia and I can help with exceptions
18:27:51 <stevemar> dolphm, eerrr, which is the right address?
18:27:58 <lbragstad> dolphm: that's the right one then?
18:28:00 <lbragstad> off pecan?
18:28:06 <dolphm> 112 East Pecan is correct
18:28:18 <ayoung> topol, lets just all go with Valencia,  nive to have a common hotel for something like this
18:28:26 <topol> ayoung+++
18:28:28 <topol> I agree
18:28:32 <henrynash> agreed
18:28:48 <dolphm> the wrong geekdom location is 110 East Houston
18:29:00 * lbragstad noted
18:29:01 <morganfainberg> dolphm,i've also been told there is a good place for whiskey around SA. adrian_otto was saying it was awesome -- so...
18:29:12 <stevemar> topol, will fix exceptions for everyone!
18:29:17 <ayoung> dolphm, is that for Keystone only, or Barbican as well?
18:29:18 <topol> wrong geekdom??? how many are there?
18:29:23 <topol> yes I will fix exceptions
18:29:38 <ayoung> at Geekdom, I mean
18:29:42 <topol> IBMer's at least
18:29:44 <dolphm> morganfainberg: the brooklynite is all i can think of
18:30:02 <morganfainberg> dolphm, is that the one owned by a racker (not sure about former or not)
18:30:05 <dolphm> ayoung: working on barbican separately, but it should be M-Tu-W same space, same week
18:30:11 <ayoung> ++
18:30:32 <dolphm> morganfainberg: uhh i dunno. the beer place we went to in january was a former racker (big hops)
18:30:46 <morganfainberg> dolphm, i'll get infos.
18:30:54 <dolphm> topol: geekdom is expanding, quite quickly. two in SA
18:31:09 <topol> impressive
18:31:14 <dolphm> topol: (within a couple blocks of each other)
18:31:41 <dolphm> #topic Reviewing languishing reviews for abandonment / re-assignment
18:31:43 <dolphm> morganfainberg: o/
18:31:47 <morganfainberg> o/
18:31:59 <morganfainberg> ok so if everyone wasn't aware auto abandonment of reviews is dead
18:32:20 <ayoung> dolphm, can we get this one for J1?  https://review.openstack.org/#/c/95989/
18:32:34 <dolphm> morganfainberg: do we have a script to identify reviews to consider for abandonment?
18:32:37 <morganfainberg> reviews will never auto-abandon, so we need to review (probably once a month / milestone/ something) the reviews that are lingering around
18:32:49 <stevemar> dolphm, i've been commenting on some
18:33:03 <stevemar> dolphm, i think any core can actually mark it as abandoned?
18:33:10 <dolphm> stevemar: thats true now
18:33:14 <dolphm> we can also Restore anything
18:33:22 <morganfainberg> dolphm, at the moment no, but i think i can scrape up the infra script that used to abandon so we can run it locally
18:33:31 <morganfainberg> but since we can restore (all cores)
18:33:36 <morganfainberg> and all cores can abandon
18:33:47 <dolphm> and i assume authors can still restore if core abandon?
18:33:52 <morganfainberg> dolphm, yes
18:34:12 <dolphm> so we're not risking too much by removing stale things from the review queue
18:34:19 <morganfainberg> we should clean up old reviews.  if a review is desired and has no movment, we need to reassign the work
18:34:47 <morganfainberg> i've been going through and cleaning up the ones i know for sure about (a couple)
18:34:49 <ayoung> dolphm, or does it need a full blueprint.
18:34:51 <ayoung> ?
18:35:55 <morganfainberg> but it shoudn't be just one person sweeping reviews up
18:36:08 <dolphm> ayoung: you mean a spec?
18:36:17 <dolphm> ayoung: let's discuss after the meeting
18:36:22 <ayoung> dolphm, yes, SPC and BP
18:36:22 <ayoung> OK
18:37:27 <dolphm> morganfainberg: next-review should make languishing reviews fairly easy to spot
18:37:38 <morganfainberg> dolphm, as will reviewday
18:37:38 <bknudson> morganfainberg: do we want to use the same rule as before? 1 week?
18:37:56 <ayoung> bknudson, that is kindof harsh
18:38:01 <bknudson> I agree
18:38:03 <ayoung> 2 weeks?
18:38:05 <ayoung> 3?
18:38:17 <morganfainberg> once a milestone, imo
18:38:25 <bknudson> doesn't seem like it costs much to have old reviews around.
18:38:27 <ayoung> you end up with a lot of "bring it back to life but not fix"  resubmits
18:38:28 <morganfainberg> or twice a milestone?
18:38:56 <morganfainberg> start of milestone: abandon / reassign, middle - did we get anywhere on those / checkin
18:39:16 <bknudson> start of milestone seems like a good time
18:39:26 <stevemar> ++
18:39:34 <bknudson> or maybe at some cutoff before the milestone
18:39:41 <bknudson> to cull out the # of reviews to look at
18:39:45 <dolphm> morganfainberg: i'd rather this not be a significant recurring cleanup effort, but rather an ongoing one
18:39:46 <morganfainberg> bknudson, sure.
18:40:06 <morganfainberg> dolphm, i don't mind which way it goes, as long as we're doing it
18:40:18 <ayoung> lets go with one month
18:40:26 <bknudson> month works for me
18:40:26 <ayoung> that is roughly how long the milestones last
18:40:27 <dolphm> after a week or two of silence, we should be leaving review comments asking if the author is available to follow up, and if not, abandon
18:40:46 <bknudson> two weeks also works
18:40:56 <dolphm> but the burden is on everyone to ping authors - bonus points if you want to pick up a patch for them :)
18:41:07 <morganfainberg> lets do 2 weeks no response, comment, 1 week later reassign/abandon
18:41:10 <dolphm> ayoung: i think they're supposed to average 6 weeks
18:41:25 <lbragstad> morganfainberg: can we write that down somewhere?
18:41:33 <bknudson> I also like the idea of if someone isn't working on something that we want we should pick it up rather than abandon
18:41:43 <ayoung> dolphm, Heh, it just feels like the Milestone one release is like a week after the summit, every single time
18:41:53 <lbragstad> morganfainberg: or point me to a spot and I can write something up
18:42:20 <morganfainberg> #info Abandonment/Reassign process: 2 weeks of no activity, ping author and ask for update, 1 week after ping (no response) review is up for abandonment or reassignment to an active contributor
18:42:25 <morganfainberg> lbragstad, ^ that work?
18:42:32 <lbragstad> lol sure!
18:42:48 <dolphm> lbragstad: it'll be in the meeting notes at least
18:42:54 <morganfainberg> lbragstad, we can put it up on wiki or in our contributing doc
18:42:59 <dolphm> #topic IDP - User / Group Lookup and Policy Functionality
18:43:01 <dolphm> morganfainberg: o/
18:43:17 <morganfainberg> really quickly
18:43:21 <morganfainberg> #link https://review.openstack.org/#/c/93982/
18:43:28 <ayoung> I think with the sahdow table it becomes:
18:43:31 <ayoung> I have user ID
18:43:38 <ayoung> I look in shadow table to find IdP
18:43:47 <morganfainberg> this review brought up an interesting proposition, do we hard-validate users and groups on grant creation
18:43:48 <morganfainberg> right now v2 doesn't validate
18:43:52 <ayoung> so question is:  what if it is not in the shadow table
18:44:04 <morganfainberg> v3 does, but as a side effect fo the policy enforcement decorator
18:44:06 <dolphm> ayoung: then it's not a valid ID?
18:44:10 <ayoung> can I assign to a user, based on userid without them being in the shadow table
18:44:18 <bknudson> V2 only has admin or public I think, no policy
18:44:20 <morganfainberg> the callback for enforcement that is
18:44:22 <henrynash> shadow table?
18:44:25 <ayoung> dolphm, so,  what if I am setting up a role for a user before thye hit the system
18:44:31 <morganfainberg> henrynash, the unique id mapping table
18:44:31 <ayoung> LDAP,  new guy is coming on board...
18:44:37 <dolphm> bknudson: that binary state actually uses policy, lightly
18:44:50 <henrynash> ahh. you mean the one I’m proposing - Ok, got it
18:44:54 <dolphm> henrynash: the mapping table
18:44:55 <ayoung> yeah, yeah, should use a group, but readonly LDAP ....
18:45:02 <dolphm> lookup table?
18:45:05 <morganfainberg> we just need to make the behavior consistent in apis
18:45:11 <dolphm> morganfainberg: ++
18:45:17 <morganfainberg> dolphm, consistent ID proposal
18:45:27 <ayoung> morganfainberg, either we don;'t look up, or we need a way to prepopulate the lookup table
18:45:35 <morganfainberg> if we go with "don't validate" we need to rethink how policy works for the v3cloud enforcement style
18:45:36 <dolphm> morganfainberg: i'm just trying to remember how we were referring to the proposed table
18:45:46 <morganfainberg> if we go with validate, v2 needs to check and we should make it explicit
18:45:51 <ayoung> I've been calling it the shadow user table
18:45:58 <ayoung> but I think the official nam,e is IDMapping
18:46:16 <morganfainberg> dolphm, hm. Unified UserID :P
18:46:23 <ayoung> henrynash, ^^ is that really a good name?  should be at least user_id_mapping
18:46:56 <henrynash> ayoung: teh table is id_mapping….remember it has groups in it too
18:47:01 <ayoung> right
18:47:15 <dolphm> henrynash: should we not have two tables then?
18:47:36 <ayoung> henrynash, maybe identity_mapping...I realize ID means identitifier, but it tends to be read as meaning id for any table...
18:47:53 <ayoung> dolphm, nah, so long as it has a type field, one table is better
18:48:08 <henrynash> dolphm: we could indeed…since we need to store the type of entity since its possible that a backend might be using a different name spec for users and groups and they could have the same ID
18:48:09 <ayoung> just like the role assignment table, makes joins easier
18:48:19 <dolphm> ayoung: explain "better"
18:48:24 <bknudson> I don't think indexes on type fields are very efficient
18:48:34 <ayoung> what do we call it there? target is the project side...
18:48:47 <morganfainberg> bknudson, unless the type is an int :P
18:48:49 <dolphm> bknudson: ++ it just seems like an extra, unnecessary index
18:49:17 <dolphm> morganfainberg: is_user (tinyint)
18:49:30 * dolphm is slightly sarcastic ^
18:49:31 <bknudson> an int might be ok, but if every other row is a different type then there's no good way to index.
18:49:35 <henrynash> right now its an Enum
18:49:37 <ayoung> this is the assingment tablehttp://paste.openstack.org/show/82655/
18:49:44 <ayoung> http://paste.openstack.org/show/82655/
18:49:54 <ayoung> we could call it the actor table
18:50:15 <henrynash> i knew that name would come back and bite me!
18:50:21 <bknudson> although I would expect lots more users than groups
18:50:29 <bknudson> so maybe not a big deal in this case
18:50:33 <henrynash> bknudson: ++
18:50:34 <ayoung> type      | enum('UserProject','GroupProject','UserDomain','GroupDomain')
18:50:42 <ayoung> so enum ('User' 'Group'
18:50:44 <ayoung> )
18:50:58 <ayoung> henrynash, I like actor
18:50:58 <henrynash> ayoung: that’s what i have in teh code today for it!
18:51:03 <morganfainberg> so.. i know we need to solve the user id thing as well. i'd like to just make sure we solve what we want with policy and fixing v2/v3 policy post meeting so we can write it up/code it up/etc
18:51:12 <ayoung> henrynash, I know, and I was supporting your approach
18:51:16 <morganfainberg> (either accept the review that is posted or not enforce existence)
18:51:23 <henrynash> ayoung: bows head
18:51:36 <morganfainberg> dolphm, i think we're into henrynash's topic here. :)
18:51:48 <dolphm> morganfainberg: was just thinking that
18:52:12 <dolphm> although i wasn't sure what the difference between the two was intended to be...
18:52:14 <dolphm> #topic Cross-backend Unique User and Group Entity IDs
18:52:21 <dolphm> henrynash: o/
18:52:28 <henrynash> so woudl encourage peopel to read the spec!
18:52:47 <morganfainberg> dolphm, mine is just about policy enforcement consistency in absence of anything else.
18:52:48 <stevemar> i'm going to appoint henrynash to write up all the specs
18:52:51 <dolphm> #link https://review.openstack.org/#/c/97492
18:52:56 <dolphm> #link https://review.openstack.org/#/c/74214/
18:53:01 <henrynash> thx
18:53:18 <morganfainberg> and user must/exist/not exist before grant assigned
18:53:22 <ayoung> henrynash, is there some way to prepopulate a value in the actor table?
18:53:54 <ayoung> If I need to do a role assignment, but the user hasn't logged in,  would a GET check in LDAP for the user and then add to the shadow table?
18:53:58 <henrynash> well, do we know he local identifiers?
18:53:59 <ayoung> actore table?
18:54:21 <ayoung> henrynash, yes
18:54:34 <henrynash> ayoung: so any identity manger call that causes the backend entity to be read will populate the mappintable
18:54:41 <dolphm> actore mensamque*
18:54:47 <ayoung> henrynash, list_users?
18:54:49 <henrynash> yep
18:55:02 <ayoung> that could be expensive the first time it is run....
18:55:06 <ayoung> is that OK?
18:55:21 <henrynash> well I guess someone will hit it
18:55:50 <henrynash> do we know the user name?
18:56:04 <henrynash> then just do a list with tehuser name as the filter
18:56:13 <ayoung> henrynash, I think the only things that accept user name are authenticate and list users
18:56:23 <ayoung> GEt takes userid
18:56:44 <henrynash> ahh no - ther is a get user by name manager call
18:56:55 <ayoung> in V#?
18:56:57 <ayoung> V3
18:56:58 <henrynash> def get_user_by_name(self, user_name, domain_id):
18:57:06 <bknudson> If I do a list all users will all the users get populated?
18:57:32 <bknudson> in the mapping table
18:57:39 <henrynash> bknudson: first, we insist that you at least qualify teh list with a domain_od
18:57:53 <ayoung> henrynash, that is only called from an extension
18:58:16 <henrynash> ayoung: teh get user byname?
18:58:22 <ayoung> henrynash, I think so, yes
18:58:27 * ayoung still confirming
18:58:33 <henrynash> ayoung: it’s in teh identity core manager
18:58:39 <bknudson> ok, if I list all users in a domain then all the users for that domain get populated?
18:58:46 <morganfainberg> dolphm, ~2min
18:58:48 <henrynash> bknduson: yes….
18:58:59 <bknudson> ok
18:59:27 <dolphm> you can't actually list users from a federated source
18:59:46 <henrynash> dolphm: from LDAP yes, from federated no
18:59:53 <ayoung> dolphm, we need a way to get a userid from a username for federation
18:59:55 <dolphm> henrynash: maybe and correct
19:00:02 <dolphm> (time)
19:00:03 <ayoung> or at least for LDAP
19:00:03 <dolphm> #endmeeting