18:02:53 <morganfainberg> #startmeeting Keystone
18:02:53 <openstack> Meeting started Tue Aug  5 18:02:53 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:56 <stevemar> o/
18:02:57 <openstack> The meeting name has been set to 'keystone'
18:03:14 <morganfainberg> ok so a relatively short agenda today
18:03:26 <morganfainberg> #topic Reviewing code
18:03:36 <morganfainberg> #link http://dolphm.com/reviewing-code/
18:03:42 <ayoung> morganfainberg, where is "Items we were arguing about last meeting that we didn't resolve?"
18:03:49 <morganfainberg> bknudson, you said dolphm wasn't going to be making it?
18:03:59 <bknudson> morganfainberg: y, he posted in irc
18:04:01 <morganfainberg> ayoung, add it to the end of the agenda?
18:04:15 <morganfainberg> ok so Dolph wrote a cool blog post about reviewing code
18:04:18 <bknudson> some kind of family emergency
18:04:26 <stevemar> morganfainberg, link?
18:04:27 <morganfainberg> bknudson, *nod*
18:04:31 <morganfainberg> ^^
18:04:34 <morganfainberg> #link http://dolphm.com/reviewing-code/
18:04:39 <stevemar> oops
18:04:49 <ayoung> That is "why"
18:04:51 <morganfainberg> it's worth a read.
18:04:53 <ayoung> I think we need a "how"
18:04:59 <ayoung> Code reviews suck
18:05:03 <ayoung> and I suck at code reivews
18:05:16 <ayoung> a couple points:
18:05:23 <ayoung> if you are going to -1 for a nit.  Don't
18:05:24 <henrynash> north>
18:05:28 <ayoung> Fix it  and resubmit
18:05:32 <ayoung> or shut up
18:05:32 <marekd> ayoung: ++
18:05:34 <morganfainberg> henrynash, east
18:05:40 <bknudson> here's a review checklist -- https://wiki.openstack.org/wiki/ReviewChecklist
18:05:44 <ayoung> obviosuly, the first is preferable
18:05:54 <morganfainberg> #link https://wiki.openstack.org/wiki/ReviewChecklist
18:06:06 <ayoung> second...run through the code.  Ideally in a debugger
18:06:10 <henrynash> ayoung: so is that preferabe?  Would some peopel object to you doing that?
18:06:17 <ayoung> nothing quite like seeing how the code works
18:06:23 <ayoung> henrynash, would you?
18:06:54 <henrynash> ayoung: no, but I am always concerend that people take time to grow the thick skins needed to survive in an open source envornment
18:06:54 <ayoung> henrynash, if its a real nit, then fix it.  If the origianly author has an issue with that, they can revert, or they can accept
18:06:55 <morganfainberg> ideally follow the checklist
18:07:20 <bknudson> requiring the reviewer to submit the fix creates a higher barrier to reviewing.
18:07:28 <dstanek> ayoung: especially for newcomers i'd rather give them the change to fix the nit and feel like a part of the process
18:07:29 <morganfainberg> bknudson, ++
18:07:47 <dstanek> s/change/chance/
18:07:48 <ayoung> We.kill.progress.
18:07:55 <morganfainberg> ayoung, no we don't.
18:07:56 <ayoung> We are not good at this
18:08:10 <morganfainberg> ayoung, we need to use our best judgement on when to submit a fix covering a nit and when not to
18:08:20 <ayoung> morganfainberg, we need to start saying yes
18:08:22 <ayoung> not always
18:08:27 <ayoung> but a hell of a lot more than we do
18:08:36 <morganfainberg> ayoung, i actually disagree
18:08:45 <topol> o/
18:08:47 <gyee> yes!
18:08:55 <henrynash> ayoung: we do need to educate people a little then on how to take the change that someone else updated to your patch, typical newbie practice probaly wouldn;t know how to do that
18:09:04 <morganfainberg> henrynash, ++ better than i coudl have said it
18:09:12 <morganfainberg> (and beat me to the typing)
18:09:45 <stevemar> henrynash, i didn't think that was an issue
18:09:50 <stevemar> but yeah, i guess it would be
18:10:17 <morganfainberg> but the point is valid, don't hesitate to fix a nit if it really is the reason holding up a patch and you can afford to do so, at the very least make sure you clearly mark it as a nit if it is one. other reviewers can override +1/+2 if it's only nits
18:10:28 <henrynash> agreed
18:10:44 <morganfainberg> there shound't be a requirement to fix nits though (on the reviewer)
18:10:47 <ayoung> I think, also, that if a core fixes a nit, you should still be comfortable +2ing it
18:10:49 <ayoung> not just +1
18:11:03 <ayoung> maybe get the origianl author to +1 before you +a
18:11:10 <henrynash> ayoung: ++
18:11:14 <morganfainberg> ayoung, i'd rather defer that call to dolphm but i don't have an issue with it.
18:11:40 <ayoung> morganfainberg, I want to clear the Queue of client changes.
18:11:51 <dstanek> i don't mind the +2, but i wouldn't +A something that i pushed
18:12:24 <henrynash> ayoung: we just need to make sure that submitters realize we’re helping, not implying they don’t know how to fix their code right
18:12:27 <henrynash> dstanek: +
18:12:41 <ayoung> dstanek, I'd +a it after someone else saw it, either the origianl author or another core
18:12:57 <stevemar> morganfainberg, then we run the risk of deferring too much to dolphm
18:13:11 <morganfainberg> stevemar, no i mean policy
18:13:11 <stevemar> oh you meant the actual rule change..
18:13:15 <morganfainberg> stevemar, yes
18:13:25 <morganfainberg> stevemar, not each review :)
18:13:41 <stevemar> yep, my bad
18:13:48 <henrynash> morganfainberg: naaah, assign every review that has a nit to dolph
18:13:52 <morganfainberg> stevemar, it's ok you're on holiday.
18:14:20 <morganfainberg> ok i think we've covered most everything here
18:14:26 <ayoung> we've 10 core now.  That should mean that things move faster, not slower
18:14:41 <morganfainberg> ayoung, and it has picked up some speed
18:14:46 <dstanek> ayoung: are things moving slower?
18:15:02 <morganfainberg> by view it has improved since we added lbragstad
18:16:24 <ayoung> We have two full pages of server reviews and a full page of client reviews.  For the middleware we have half a page
18:16:43 <bknudson> we do seem to be getting more submissions too
18:16:54 <morganfainberg> ayoung, and a bunch of those reviews have been WIP/not touched on jenkins failures.
18:17:02 <bknudson> the specs process has also slowed things down, maybe?
18:17:06 <morganfainberg> bknudson, it has
18:17:14 <ayoung> Yep.
18:17:16 <morganfainberg> ayoung, we also have some reviews that are pending specs.
18:17:25 <ayoung> morganfainberg, yeah.
18:17:26 <morganfainberg> code talks as topol likes to say, so spec is up, so is code
18:17:28 <bknudson> since we're expecting a spec to be approved and we're maybe not reviewing those with enough urgency
18:18:00 <jamielennox> ++ i still haven't seen approval/denial of my specs to start doing actual implementation
18:18:13 <morganfainberg> the specs also don't see a fast turn-around on comments from the spec authors
18:18:14 <jamielennox> with a blueprint i'd have code in to prove it by now
18:18:29 <morganfainberg> i frquently look at specs and see a bunch of the comments and no follow up from the author
18:18:29 <ayoung> yeah, specs not really what I want
18:18:41 <ayoung> I want a backlog and code
18:18:47 <ayoung> specs are just busywork
18:19:05 <morganfainberg> lets defer the spec specific topic.
18:19:08 <henrynash> ayoung; I disagree
18:19:12 <ayoung> especially when you post something to get a sense of the rightness of solution and people start attacking grammar
18:19:19 <dstanek> morganfainberg: yes, i don't even bother with those
18:19:24 <morganfainberg> ayoung, specifically changing the spec workflow
18:20:30 <ayoung> morganfainberg, henrynash specs as documents are a good tool. but specs as fodder for bikeshedding is not
18:20:33 <henrynash> ayoung: on grammar, i do agree!
18:20:52 <morganfainberg> it is a topic we do need dolphm around for imo, so we can follow up witht hat either in -keystone or next meeting, but i don't think anything we do today will change this week
18:21:02 <ayoung> henrynash, I would prefer it if the specs were designed to be the final documentation
18:21:05 <henrynash> (someone needs to explain the bikeshedding analogy to me, doesn’t work in the UK)
18:21:07 <ayoung> not the  design
18:21:14 <morganfainberg> henrynash, bikeshed.org
18:21:20 <ayoung> design should be light and fast, and we should switch to code
18:21:56 <bknudson> it's probably too late for juno, how about we have a proposal for specs for kilo?
18:21:57 <henrynash> morganfainberg: ahh, all is revealed...
18:22:50 <ayoung> OK...back to "how to do a decent code review"
18:22:53 <morganfainberg> bknudson, i think if we did what Nova did and have specs open up for the cycle a bit beforehand (so they can be approved pre-<cycle>-1 start) would help a lot
18:22:54 <henrynash> ayoung: agree on teh design side…….and the key things about specs for me is “Is this a sensible thing we want to be doing”
18:22:55 <ayoung> I thinkgertty is a key piece
18:23:04 <ayoung> it makes it really easy to do "local checkout"
18:23:08 <morganfainberg> ayoung, lets leave specific tools out of this.
18:23:14 <ayoung> and I would request that all of you to try it out
18:23:19 <ayoung> morganfainberg, no, this is important
18:23:25 <ayoung> it doesn't have to be gertty, buit it helps
18:23:26 <dstanek> ayoung: gertty isn't great yet
18:23:33 <marekd> ayoung: link?
18:23:33 <morganfainberg> ayoung, no telling folks to use a specific workflow is wrong.
18:23:37 <ayoung> you can do it using next-review or whatever
18:23:38 <dstanek> git review -d #
18:23:51 <ayoung> #link https://git.openstack.org/cgit/stackforge/gertty/tree/README.rst
18:23:59 <marekd> ayoung: ty
18:24:01 <ayoung> gertty is rough, I'll admit
18:24:02 <morganfainberg> ayoung, i find gertty to be insufficient atm. it breaks far too much and is too early development
18:24:09 <morganfainberg> it's cool, but it's not primetime ready yet
18:24:13 <ayoung> but the low barrier to check out might be its killer feature
18:24:25 <morganfainberg> ayoung, git review -d #reviewnumber
18:24:30 <ayoung> also an option
18:24:31 <morganfainberg> about the same barrier to entry
18:24:47 <ayoung> whatever works for you, so long as you run through the cdoe with a debugger
18:24:55 <ayoung> and...that is the real pain point
18:25:03 <ayoung> using a debugger with eclipse or pycharm is trivial
18:25:10 <ayoung> for the vi users...not so mucjh
18:25:12 <ayoung> much
18:25:24 <bknudson> good luck running through the federation code with a debugger... all I have to do is setup apache and mod_shib and a saml provider!
18:25:25 <dstanek> everyone could use 'next-review' and 'git review -d #' and i think that would be enough
18:25:27 <ayoung> anyone have any advice
18:25:34 <ayoung> bknudson, funny you should say that
18:25:34 <morganfainberg> dstanek, ++
18:25:45 <ayoung> I have a method for remote debugging HTTPD WSGI code now
18:25:50 <ayoung> I need to complete the blog post
18:25:53 <ayoung> but I will; do so
18:26:07 <dstanek> ayoung: yeah, pydev :-(
18:26:19 <morganfainberg> dstanek, unfortunately one of the few options
18:26:29 <marekd> pdb
18:26:35 <ayoung> dstanek, is there a standard way to remote debug without an IDE for python?
18:26:36 <dstanek> i use rpdb right now so that i can use real debugging tools
18:26:36 <marekd> fo vi users....
18:26:54 <ayoung> marekd, link?
18:27:02 <bknudson> rpdb??
18:27:10 <morganfainberg> #link https://pypi.python.org/pypi/rpdb/0.1.4
18:27:12 <marekd> ayoung: * pdb for users ;/
18:27:16 <dstanek> i debug usually in vim, but sometimes in winpdb
18:27:31 <bknudson> neat
18:27:44 <dstanek> i won't install eclipse on principle
18:27:49 <morganfainberg> dstanek, lol
18:27:55 <morganfainberg> dstanek, not a bad principle imo
18:27:56 <ayoung> dstanek, I hear you.  and maybe rpdb is the answer there
18:28:30 <dstanek> i think winpdb hasn't been updated in a while and unless you really like vim you probably don't want to follow me into vimpdb
18:28:33 <ayoung> marekd, I assume its :run a listener, run your code, your code attaches to listener at breakpoint?
18:28:54 <morganfainberg> ok, sorry to stop us here, but we have some other topics we need to address
18:29:11 <marekd> ayoung: i simply go the the code, add pdb.set_trace() and tun the code...
18:29:15 <ayoung> fair enough
18:29:15 <morganfainberg> we can talk specific tools and howtos in blogs and outside of the meeting if no one minds
18:29:34 <ayoung> #action marekd to write up using rpdb for Keystone
18:29:43 <morganfainberg> #topic Federated users have no domain in token
18:29:44 <ayoung> #action ayoung to write up using pydevd  for Keystone
18:29:47 <morganfainberg> stevemar, o/
18:29:55 <stevemar> o/
18:29:56 <marekd> ayoung: i didn't mention rpdb.
18:29:58 <morganfainberg> stevemar, since you wrote the patch for this, i'll let you lead
18:30:05 <stevemar> o thx
18:30:11 <ayoung> #action dstanek to write up using rpdb for Keystone
18:30:38 <dstanek> ayoung: ++
18:30:44 <stevemar> basically a bunch of things (like non-persistent token model, and middleware) depend on the 'user' portion of the token having a 'domain' section
18:30:58 <stevemar> but we don't have that in federation issue tokens
18:31:08 <stevemar> we had 2 ideas to solve this
18:31:22 <stevemar> 1) add a dummy domain of 'federated'
18:31:31 <ayoung> bleh
18:31:32 <stevemar> or 2) add the idp id
18:31:35 <ayoung> YAY!
18:31:36 <henrynash> stevemar: and this is the domain the user is supposed to be owned by?
18:31:44 <morganfainberg> henrynash, correct
18:31:44 <stevemar> henrynash, correct
18:31:52 <ayoung> OK,  my thought was that idp == domain id is the degenerate case
18:32:00 <stevemar> neither will work if you query /v3/domains/{domain_id}
18:32:03 <morganfainberg> 3) fix auth_token / client / etc to not care
18:32:03 <ayoung> in a more complex case, one Idp could support multiple domains
18:32:13 <stevemar> right, thx morganfainberg
18:32:17 <jamielennox> morganfainberg: ++
18:32:20 <marekd> morganfainberg: which is a cross-project task I guesss ;/
18:32:21 <bknudson> we could make a dummy domain work
18:32:32 <jamielennox> what is the value to user_domains in the federated case?
18:32:34 <morganfainberg> marekd, potentially and could affect external consumers of the token
18:32:36 <bknudson> well, we could make a idp_id domain work, too.
18:32:42 <marekd> morganfainberg: exactly.
18:32:43 <jamielennox> or in general i guess, why can't they be optional?
18:33:02 <ayoung> if userid always leads to domain id, we will just be punting on the problem in auth token
18:33:11 <morganfainberg> jamielennox, because we have sucked at documenting the token format, and we have a few special case formats.
18:33:22 <ayoung> if you create an idp, you get a  domain to go with it
18:33:23 <morganfainberg> jamielennox, we should define the format of the token and ensure that it conforms.
18:33:47 <morganfainberg> ayoung, which only works in the SQL assignment backend at the moment
18:33:55 <morganfainberg> ayoung, you *could not* do that with ldap assignment
18:33:57 <jamielennox> ok, so let's document this correctly, lets and ['user']['idp']['id'] rather than try and stick it into domain
18:34:06 <jamielennox> s/and/add
18:34:16 <morganfainberg> jamielennox, we already have OS-FEDERATED:idp
18:34:33 <morganfainberg> jamielennox, most optional items are OS-XXXXX:<something>
18:34:38 <morganfainberg> in the token iirc
18:35:00 <ayoung> morganfainberg, LDAP should be treated like any other IdP
18:35:03 <jamielennox> ok, so it would seem to me that should be enough and we just say that domain id is optional
18:35:08 <henrynash> ayoung: ++
18:35:10 <ayoung> so the domain id would go in the domain table for LDAP
18:35:12 <morganfainberg> ayoung, ldap assignment not ldap identity
18:35:45 <ayoung> morganfainberg, LDAP assignement  can be hacked to make it work
18:35:57 <ayoung> its already sick and twisted, you wouldn't even notice
18:36:35 <henrynash> stevemar: so I assume tt would be obvious to someone procesing token data that this was a federated user so to not expect a domain?
18:37:01 <stevemar> henrynash, well i hope so
18:37:30 <ayoung> OTOH morganfainberg if we explicitly said that IdP id == domain id, we could change the verbage over time so that IdP replaces domain when talking about users and groups,
18:38:01 <jamielennox> ayoung: that seems worse than just fixing it, because we want a domain to just be a top level project eventually
18:38:06 <ayoung> so...we could say that on a token we accept either domainid or idp id, and they are treated equivalently?
18:38:09 <bknudson> I thought hierarchical multitenancy was taking over domains
18:38:16 <stevemar> IMO sticking the idpId and the 'federated' dummy key word - are basically the same solution, neither will actually do the token any good
18:38:42 <marekd> henrynash: i think they should not know what method was used to get a *scoped* token...
18:38:45 <henrynash> jamielennox: I think actually domain-ness becomes an attribute of a project - i.e. one that allows users & grousp to be owned at that level
18:38:58 <bknudson> so I'm wondering why we need the domain id in the token?
18:39:05 <ayoung> henrynash, yes, but right now, domains own users.  That is what we want to transition
18:39:06 <bknudson> so it can be used in policy?
18:39:06 <jamielennox> stevemar: right, because if you put idp-id into the domain field then you need to figure out whether it's a real domain id or something else
18:39:23 <bknudson> (is this the nova identity v3 support work?)
18:39:24 <ayoung> so...can we remove the domain id for all users then?
18:39:26 <henrynash> ayoung: sure
18:39:37 <morganfainberg> bknudson, it's for revocation reasons, e.g. disabling a domain (only option i can think of, may not be a good *enough* option)
18:39:53 <jamielennox> henrynash: ok, but either way i don't think we want to transition the name in that way then
18:40:14 <bknudson> y, we'd need it for revocation... but we could handle revocation of idp since we do have the idp in the token
18:40:15 <henrynash> ayoung: pretty sure we use domain in prolicy rules
18:40:25 <ayoung> It will once again mess up revocation events, but we are used to that
18:40:29 <morganfainberg> bknudson, right.
18:40:48 <morganfainberg> henrynash, we do, no one else really does afaict
18:41:08 <jamielennox> does this mean that we make idp-id a top level concept?
18:41:11 <ayoung> morganfainberg, of course they do
18:41:22 <jamielennox> assign an id to SQL and LDAP backends
18:41:27 <morganfainberg> ayoung, in policy?
18:41:32 <ayoung> morganfainberg, yeah
18:41:33 <bknudson> jamielennox: it does seem like idp/federation should be a core concept.
18:41:40 <morganfainberg> ayoung, which project does?
18:41:40 <ayoung> morganfainberg, maybe not the other core projects, but end users
18:41:55 <morganfainberg> ayoung, the user's domain?
18:41:57 <jamielennox> bknudson: i think bits of it definetly should be, and IDP id would be one
18:42:00 <ayoung> people are doing unspeakable things out there
18:42:13 <henrynash> morganfainberg: wel, it’s about the only way you can create an idea of a “cloud admin”…i.e. users in a special domain with a given role get more powers that others
18:42:25 <morganfainberg> henrynash, right, keystone absolutely uses it
18:43:00 <henrynash> ayoung: so no, I don’t think we can remove domain_id
18:43:11 <ayoung> "I've... seen things you people wouldn't believe..."
18:43:50 <bknudson> so I think we solved it
18:44:31 * ayoung blinks
18:44:33 <ayoung> we did?
18:44:56 <bknudson> there was a lull so I assumed that meant we'd solved it
18:45:02 <morganfainberg> bknudson, lol
18:45:28 <morganfainberg> so the best option sounds like federated users don't get domain_ids and we fix everything else?
18:45:40 <ayoung> "lost in time, like [small cough] tears... in... rain. Time..."
18:45:43 <jamielennox> agreed
18:45:44 <henrynash> morganfainberg: I agree
18:45:49 <marekd> +++++
18:45:54 <ayoung> blah
18:46:02 <henrynash> bknudson: you were right, master
18:46:04 <ayoung> either everyone gets it
18:46:06 <ayoung> or no one
18:46:24 <dstanek> "if i can't have it, nobody can"
18:46:33 <henrynash> toys, pram, out
18:46:38 <ayoung> we've inflicted our half-thought-through domain concept on the rest of openstack.  We can't break it now
18:46:42 <morganfainberg> henrynash, i think we can probably drop a user's domain id attribute across the board, but it would be a bunch of work
18:46:50 <morganfainberg> henrynash, in the token that is
18:46:51 <ayoung> Lets make the IdP id the domain id
18:47:06 <ayoung> and lock them one-to-one
18:47:21 <jamielennox> ayoung: that will screw us longer term
18:47:27 <ayoung> jamielennox, how
18:47:42 <jamielennox> because we have assumptions on things like domain owns project
18:47:46 <ayoung> how is that worse than screwing all Openstack deployments by yanking domains
18:47:51 <ayoung> So what
18:48:03 <ayoung> we can make domains that don't have Idps, just not the reverse
18:48:04 <jamielennox> if idp becomes domain then we break the whole existing point of domains
18:48:15 <bknudson> https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#authentication-responses
18:48:20 <ayoung> and, in the future we drop domains as the way of talking about users, and only say idps
18:48:22 <bknudson> here's what we document for the response
18:48:29 <morganfainberg> bknudson, ah, we documented the token that way
18:48:37 <morganfainberg> bknudson, i guess we can't rip that out then can we?
18:48:38 <bknudson> so you're saying for federation there's no "domain" section in "user"?
18:48:38 <ayoung> We are stuck with out mistakes.
18:49:11 <bknudson> maybe this would be documented in the federation extension
18:49:39 <henrynash> how about we think about this is terms of when keystone idenitity becomes an idp
18:50:36 <henrynash> surely we want to ADD an “idp” section to teh token, which woudl be “keystone” for ours, and domain is only required for keystoen idps users
18:50:55 <ayoung> henrynash, V4
18:50:56 <bknudson> I don't see anything in the federation spec that says the token format is different -- https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-federation-ext.md
18:51:08 <ayoung> V3 api is built around the domain concept
18:51:44 <bknudson> henrynash: but when we have keystone identity as an idp we might want to simplify it... one domain per identity idp
18:51:53 <henrynash> V3 was also built around the idea (origionally) taht all users were “visible” vai keystone, which they aren’t with federation
18:52:29 <morganfainberg> i don't want to cut this short but we have one more topic, if henrynash doesn't mind delaying we can continue this convo
18:52:34 <henrynash> bknudson: so we’d have multiple keystone idps ( to map to the current situation)?
18:52:50 <bknudson> henrynash: y, if you have multiple domains.
18:53:09 <henrynash> morganfainberg: agreed….my only request was so more eyes on: https://review.openstack.org/#/c/99842/
18:53:31 <morganfainberg> ok so lets continue this topic
18:53:44 <morganfainberg> 7 minutes till end fyi
18:54:14 <morganfainberg> i think the question is, should IDPs care about domains (and i don't mean from a grant perspective)
18:54:31 <morganfainberg> if idps don't care about domains (i don't see the benefit), we don't need to lock it to idp == domain
18:54:37 <dstanek> i just took a look at the numbers and keystone commits are not slowing down - https://www.dropbox.com/s/4dh3tc8mr1ja94b/Screenshot%202014-08-05%2014.53.18.png
18:54:39 <henrynash> bknudson: but does that map to how we user external idps today…..e.g. teh facebook idp could assert to multiple domains
18:56:12 <bknudson> henrynash: I thought we were just discussing that idps didn't know anything about domains.
18:56:27 <ayoung> henrynash, endpoint policy?
18:56:30 <morganfainberg> bknudson, i think henrynash is claiming that.
18:56:59 <bknudson> so an identity idp wouldn't know anything about domains
18:57:23 <morganfainberg> henrynash, if i'm understadning you, idps don't care about domains and could assert for any domain today, right?
18:58:32 <bknudson> an identity idp would have to work like any other idp... it returns a bag of attributes that get mapped to user ID and groups
18:58:59 <ayoung> henrynash, what did you want to ask about endpoint policy?
18:59:05 <henrynash> morganfainberq: it seems to me that this should be true, I can imagine large idps doin that…I guess teh questions is whether an IdP ID that we store internally can point at multiple domains, or whether we crreate a new reprsentation of that idp (i.e. a new IDP ID) for eavery domain
18:59:36 <ayoung> henrynash, one to one for now,  one to many if it gets requested in the future
18:59:39 <henrynash> ayoung: morganfainberg: asked if I would defer….I said yes - as long as peopel get eys on teh spec
18:59:40 <morganfainberg> henrynash, i don't like the tight coupling of idpid to domain_id personally, but i think it adds a lot of overhead and complexity
18:59:47 <ayoung> KK
19:00:52 <morganfainberg> henrynash, bknudson, i think we have 2 options at the moment (due to the spec) 1: dummy domain, 2: idpid == domain id
19:00:58 <morganfainberg> unfortunately that is time :(
19:01:04 <morganfainberg> take this back to -keystone
19:01:08 <morganfainberg> #endmeeting