18:06:43 <dolphm> #startmeeting
18:06:44 <openstack> Meeting started Tue Jun  5 18:06:43 2012 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:06:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:06:59 <dolphm> might as well get started
18:07:11 <dolphm> fyi- joe heck is traveling today, so i'll be proxying for him
18:07:40 <ayoung> #topic Status and Progress
18:07:53 <ayoung> Not sure if I can even do that...
18:07:56 <dolphm> #topic status and progress
18:08:10 <ayoung> guess not
18:08:12 <dolphm> might be tied to whoever did startmeeting (?)
18:08:32 <dolphm> gyee: did you want to give us an update on bp keystone-domains?
18:08:37 <gyee> yep
18:08:41 <dolphm> I know it took some extra effort/time to get the draft review going
18:08:57 <gyee> I uploaded the initial version to gerrit for draft review
18:09:04 <gyee> anyone else want to be included?
18:09:07 <ayoung> #link http://etherpad.openstack.org/keystone-domains
18:09:25 <ayoung> gyee, yes, please
18:09:36 <rafaduran> gyee, me too please
18:09:43 <gyee> got it
18:09:58 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/keystone-domains
18:10:10 <gyee> I'll be finishing up the architectural doc some time this week
18:10:26 <ayoung> gyee, post link?
18:11:07 <liemmn> gyee, you want to summarize the core concepts for domain here?  (for those who are not familiar with it yet)
18:11:12 <gyee> https://review.openstack.org/#/c/8114/
18:11:20 <gyee> its a draft review so I'll have to add you guys in
18:11:24 <gyee> not yet public
18:12:16 <gyee> conceptually, domains are administrative boundaries/containers for users, tenants, and optionally roles
18:12:32 <ayoung> gyee, alternatively,  you could do what I've been doing for "signed tokens"  which is posting it to github.  Might make more sense
18:12:56 <gyee> ayoung, yet, that'll work too
18:12:59 <tongli|2> so domain will have roles associated?
18:13:23 <gyee> role definitions can be either domain-agnostic or domain-specific
18:13:24 <tongli|2> which limit or grant certain action rights?
18:13:42 <dolphm> gyee: i'm not a fan of that extra complexity at all
18:13:49 <tongli|2> right, but it will be associated with domain, correct?
18:13:58 <gyee> dolphm, its flexibility
18:14:02 <dolphm> tongli|2: correct, there's a domain-role association table in the implementation
18:14:25 <dolphm> gyee: flexibility to achieve what specific use cases?
18:14:52 <tongli|2> in that case, how will it be different from user groups?
18:15:02 <termie> the goal is to provide the ability for somebody to be a domain admin
18:15:12 <gyee> termie, correct
18:15:22 <gyee> separation of duties, delegate administration, etc
18:15:32 <termie> the simplest implementation would be to add an additional category of roles that is a user-domain role, rather than a user-tenant role
18:15:41 <termie> gyee: i don't buy the rest of that
18:16:04 <termie> my goal is to allow a domain administrator with the same policy semantics as already exist
18:16:09 <gyee> what's user-domain role?
18:16:20 <tongli|2> I thought that during the design summit, the decision was made clear that delegation should not be in keystone.
18:16:29 <termie> gyee: a role that applies to a user-domain pair, rather than a user-tenant pair
18:16:44 <dolphm> tongli|2: that's correct
18:16:45 <gyee> so all tenants in that domain will have that role?
18:16:51 <termie> gyee: any tenant that user is using within a given a domain will provide in additon to "roles" a set of "domain-roles"
18:16:56 <termie> gyee: no
18:16:59 <termie> gyee: it is user-domain
18:17:04 <termie> not tenant-domain
18:17:29 <termie> whenever that user is operating within that domain they have some domain-roles associated
18:17:30 <gyee> so if I authenticate and scope to a tenant in that domain, will I get that role?
18:17:34 <jr__> domain is a collection of users, tenants, roles, and groups... not just users or just roles
18:17:51 <termie> jsut as whenever the user is operating within a tenant they will have the normal roles they have associated with that tenant
18:17:56 <termie> jr__: wrong
18:18:01 <termie> jr__: a domain is a collection of tenants
18:18:05 <jr__> wrong
18:18:09 <dolphm> jr__: i'd argue that it's not users or roles at all, it's just a collection of tenants, everything else is implicit
18:18:15 <dolphm> if at all
18:18:17 <jr__> I wrote the domain spec, i think i would know
18:18:27 <termie> jr__: i rejected the spec
18:18:33 * ayoung grabs some popcorn
18:18:56 <jr__> just a collection of tenants provides little value
18:19:20 <termie> jr__: we went over this all at the design conf, the needs you were trying to address were all addressed
18:19:31 <termie> as were the needs of the others interested in such a concept
18:19:56 <termie> i am not sure which person you were in the meeting
18:20:06 <termie> but i do recall one person with a grumpy face after it
18:21:19 <termie> morale of the story: we are not trying to incorporate HP's system into keystone, we are trying to solve the same problems in a way that works for other people as well
18:21:36 <termie> s/morale/moral/ (i'm not really that into morale)
18:22:09 <jlr> grouping of tenants is just 'grouping' of tenants.  it does nothing for separation of duties and all the other goodness provided
18:22:31 <dolphm> isn't that where rbac comes in?
18:22:32 <termie> it does totally fine
18:22:38 <jlr> that is not what domains is about... if you want tenant grouping, then call it that and create another blueprint
18:22:46 <termie> domain-roles with the same policy semantics get you all you needed
18:23:05 <gyee> termie, can you elaborate how domain-roles work?
18:23:10 <termie> i just did man
18:23:27 <dolphm> role grants are currently performed on a user-role-tenant combination
18:23:41 <dolphm> a domain-level grant would simply be a user-role-domain combination, i presume
18:23:49 <termie> dolphm: correct
18:23:56 <gyee> k? and?
18:24:16 <termie> 11:16 <termie> gyee: any tenant that user is using within a given a domain will provide in additon to "roles" a set of  "domain-roles"
18:24:18 <termie> 11:16 <termie> gyee: no
18:24:21 <termie> 11:16 <termie> gyee: it is user-domain
18:24:24 <termie> 11:17 <termie> not tenant-domain
18:24:46 <termie> 11:17 <termie> whenever that user is operating within that domain they have some domain-roles associated
18:24:52 <termie> 11:17 <termie> jsut as whenever the user is operating within a tenant they will have the normal roles they have  associated with that tenant
18:25:17 <dolphm> use cases are documented in:
18:25:20 <dolphm> #link http://etherpad.openstack.org/keystone-domains
18:25:21 <tongli|2> I feel this is an introduction of nested tenant.
18:25:28 <termie> the domain they are operating under are defined by the tenant they are operating under
18:25:34 <tongli|2> that really hurts.
18:25:36 <termie> tongli|2: it is a collection of tenants
18:25:45 <termie> tongli|2: not nested, nested implies recursion
18:26:07 <liemmn> The intention of domain is to separate users, roles and tenants in one domain from another.  The only way to link them is via trust relationship.
18:26:09 <termie> tongli|2: in practice large organizations tend to need three levels
18:26:10 <dolphm> i'd actually prefer arbitrary tenant hierarchies rather than introducing new concepts
18:26:10 <tongli|2> right, two levels inclusion, basically like a tenant can have other tenants inside.
18:26:37 <termie> dolphm: that is a bad idea and forces your datastructures into graph traverals
18:26:57 <termie> tongli|2: not exactly, they have different properties
18:26:57 <dolphm> termie: only as deep as your real-world use case
18:27:14 <tongli|2> termie, but conceptually they are all containers.
18:27:29 <termie> tongli|2: one is a container, one is a resource owner
18:27:37 <dolphm> termie: with domains, you're forcing two levels, when one could satisfy a majority, while a minority will eventually want additional complexity
18:27:53 <termie> dolphm: additional complexity means additionally complex code
18:28:02 <termie> dolphm: and additionally complex testing, edge cases
18:28:27 <termie> dolphm: design the right system, not something you aren't going to need
18:28:35 <dolphm> termie: i haven't thought it all the way through, but it seems much simpler in terms of API-impact and implementation changes
18:29:19 <termie> dolphm: feel free to take it offline and propose such a concept
18:29:44 <termie> dolphm: if you think we should wait on domains until you write it up
18:29:51 <termie> dolphm: i'm not against that
18:30:09 <termie> as existing advocates for the domains still seem to not be on the same page
18:30:13 <dolphm> termie: i'll spend some time on it and see where my opinion lands :)
18:30:35 <termie> dolphm: keep what happened to "zones" in mind when you do ;)
18:31:30 <tongli|2> probably it will really help to make a case to describe how domain can solve that tenant and user group combination can not.
18:32:03 <termie> tongli|2: it provides an abstraction for managing multiple tenants as a group
18:32:04 <tongli|2> so we move on to open discussions now?
18:32:18 <ayoung> tongli|2, not yet, we are still on "Progress"
18:32:27 <dolphm> is anyone else not included in the domains draft review that would like to be?
18:32:30 <tongli|2> ok. not a problem.
18:32:41 <tongli|2> can you please add me?
18:32:45 <ayoung> we done on domains?
18:32:54 <dolphm> gyee: can you add tongli|2 ?
18:33:01 <tongli|2> launchpad id is litong01@us.ibm.com
18:33:25 <gyee> sure
18:33:29 <rafaduran> me too please
18:33:30 <tongli|2> thanks a lot.
18:33:44 <termie> ayoung: yes
18:34:05 <ayoung> I've gotten some good feedback on the signed tokens work
18:34:23 <rafaduran> termie: I would like to know about your opinon on the queryng by name V3 API
18:34:41 <rafaduran> this week tow duplicates for #link https://bugs.launchpad.net/keystone/+bug/972800
18:34:41 <termie> rafaduran: i wrote down comments on the doc
18:34:42 <uvirtbot> Launchpad bug 972800 in keystone "Identity backends provide get_by_name methods but  they aren't available via API" [Wishlist,Incomplete]
18:35:06 <termie> maybe this link works? https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit?disco=AAAAAEYr61Q#
18:35:11 <rafaduran> termie: sorry, I didn't see, I'm going to check
18:35:12 <termie> it looks dubious
18:35:26 <ayoung> termie, what looks dubious?
18:36:27 <dolphm> i think querying by name is pretty well discussed in the v3 draft, which is a more appropriate venue for that type of discussion
18:36:35 <dolphm> ayoung: want to give us an update on pki?
18:36:40 <ayoung> sure.
18:36:50 <dolphm> proceed!
18:36:54 <termie> added anotehr comment on the doc, didn't see dolph's question
18:36:59 <termie> ayoung: the link does
18:37:05 <ayoung> I've gotten some good feedback, with a couple *big* questions
18:37:06 <termie> ayoung: i don't know if it will work for others
18:37:22 <ayoung> termie, link worked for me
18:37:27 <ayoung> anyway
18:37:47 <ayoung> gyee, asked if signed tokens should replace the existing, or if we should keep the existing around
18:37:59 <ayoung> my gut says that if we give people the option to not change,  they won't change
18:38:18 <dolphm> ayoung: a fair assumption
18:38:21 <ayoung> I'd rather have the signed tokens out there soon and find out if it breaks things
18:38:21 <termie> ayoung: i would love for that to be the case (signed required)
18:38:32 <ayoung> termie, glad to hear it
18:38:44 <ayoung> I have been going through and fixing all of the unit tests I broke
18:38:51 <ayoung> and in doing so learning a little bit
18:39:09 <ayoung> I think it is fair to say that we would want to run those tests over both token mechanisms if we kept both
18:39:15 <ayoung> and I think that is prohibiative
18:39:31 <termie> ayoung: i don't thnkk so
18:39:40 <termie> ayoung: we have existing patterns for running tests against multiple drivers
18:40:14 <ayoung> termie, it isn't just a different driver here, though.
18:40:29 <ayoung> The logic for processing the tokens is slightly different
18:40:40 <termie> ayoung: i haven't looked at your proposed implementation, but it largely is in my mind
18:40:41 <ayoung> as the signed tokens don't need the network call, etc
18:41:11 <termie> ayoung: that just means bumping a strategy abstraction up a level somewhere
18:41:15 <ayoung> termie, take a look.  Thjere are still details to work out,  but the approach in general is pretty close.
18:41:28 <ayoung> termie, yeah,  it is starting to feel that way
18:41:50 <ayoung> there are a bunch of #termie comments and #dolph comments in there that indicate that as well
18:41:58 <ayoung> "move this to common:" type stuff
18:42:41 <ayoung> I'll post an updated patch later on today with the next set of unit tests fixed
18:43:15 <ayoung> there was also the question about whether we still want to have memcache support for ticket validation
18:43:35 <dolphm> ayoung: github link?
18:44:01 <ayoung> https://github.com/admiyo/keystone/tree/signed-tokens
18:44:14 <dolphm> ayoung: / intending to open a draft/public review?
18:44:15 <termie> ayoung: i don't think it will be the most common use case, but memcache is more robust than most people tend to think
18:44:16 <ayoung> dolphm, I've been rebasing that
18:44:34 <termie> ayoung: it has the main benefit of having built-in cleanup
18:44:35 <dolphm> #link https://github.com/admiyo/keystone/tree/signed-tokens
18:45:01 <rafaduran> termie: about the querying by name, it makes sense to me your comments, moving it under /search path makes it easier to include it as an extension rather than core, keeping core clean
18:45:21 <dolphm> rafaduran: (we're still discussing pki)
18:45:21 <ayoung> termie, it is not a question of robust,  but whether we need to shortcut the token validation.  Right now,  we cache so we don't need to go back to Keystone.  With signed-tokens,  the cost of validating is less
18:46:07 <ayoung> termie, the cost of validating is spinning up an additional process and waiting for it to finish.  THis is non-zero,  but still not too bad compared to a network call
18:46:19 <termie> ayoung: for most kinds of signed tokens, but things in multifactor auth will still probably need a temporary store
18:46:47 <ayoung> termie, sounds good.  It is easier for me to leave it in.  Just don't want that to be decision made out of lazyness
18:47:01 <ayoung> termie, are you cool with the Popen approach to running openssl?
18:47:13 <termie> ayoung: mostly i just don't think we need to ditch all the code yet, that may change shortly but i think there are probably still some uses for having it in tehre, even if it just means not re-typing half of it
18:47:44 <termie> ayoung: aye, can add an abstraction to make another machine do it for us later on
18:48:55 <dolphm> ayoung: anything else on pki for today?
18:49:04 <ayoung> termie, I would probably suggest that we use AMQP or some other local RPC to talk to a process that just cranks through validation requests saying "yes" or "no" to each if we find we need to minimize the cost of the proces start up
18:49:15 <gyee> ayoung, so token revocation will be meaningless with the PKI stuff then?
18:49:22 <ayoung> gyee, correct
18:49:33 <termie> gyee: besides pki cert revocation
18:49:41 <ayoung> gyee, I have a write up of how to do it,  but it makes things more complicated
18:49:46 <ayoung> oh
18:49:49 <termie> gyee: and things of that nature
18:50:03 <termie> i doubt it will be supported right away
18:50:05 <ayoung> when starting Keystone, I was wondering if it should self generate the certs it needs if they do not exist
18:50:31 <termie> ayoung: i agree on wanting to farm out the work, i think that is something that is second priority to getting it working
18:50:44 <dolphm> ayoung: hmm.. and write them to disk?
18:50:51 <ayoung> I was thinking more along the lines of devstack than for live deployments
18:50:53 <ayoung> dolphm, yes
18:51:13 <termie> ayoung, dolphm: i'd probably put that in the whatever setup command (like db_sync)
18:51:32 <ayoung> termie, +1
18:51:40 <dolphm> termie: agree
18:51:52 <termie> we don't want to add many additional setup steps, but it still seems like something people should be knowingly doing
18:52:07 <dolphm> but i do like the idea of auto-generating them if necessary, but perhaps just keep them in memory and throw lots of warnings about how all your tokens will be invalid if you shut down keystone
18:52:19 <termie> could probably add a flag to auto-generate for testing or whatnot
18:52:24 <ayoung> termie, so the services *are* downloading the ca certs and the signing certs in order to validate.
18:52:35 <termie> ayoung: statement or question?
18:52:38 <ayoung> I think that is OK
18:52:43 <ayoung> do you?
18:52:44 <dolphm> #allow_autogenerated_keys = False
18:53:29 <gyee> ayoung, just to clarify, so PKI token is not configurable correct?
18:53:49 <jlr> i think it should be
18:53:50 <termie> gyee, ayoung: signed token, i don't think pki is the only version of that
18:53:52 <ayoung> gyee, correct.  It will replace the token code
18:54:15 <jlr> why not an option?
18:54:16 <dolphm> ayoung: without api impact, though
18:54:20 <dolphm> ayoung: correct?
18:54:23 <ayoung> dolphm, no API impact
18:54:29 <dolphm> ayoung: just sort of renders a few calls useless
18:54:58 <ayoung> dolphm, and,  the remote services can, in theory, run with the PKI tokens and the existing auth_token middleware,  but I wouldn't want to support it
18:55:35 <gyee> ayoung, no API impact?
18:55:46 <gyee> what about the 3rd party clients don't use middleware?
18:55:47 <ayoung> gyee, no.  from an API perspective,  nothing changes
18:56:02 <gyee> well, there won't be validate token call right?
18:56:11 <dolphm> gyee: it's just not necessary
18:56:11 <ayoung> they can request a token, can use it as a blob,  send it back to keystone to validate if they want
18:56:14 <liemmn> ayoung: Even though there is no API impact, for clients that do not want to deal with certs, they are now out of option
18:56:29 <dolphm> gyee: keystone could still implement one, for clients that don't understand that they can validate signed tokens themselves
18:56:56 <gyee> ok, so it's backward compatible then
18:57:01 <dolphm> gyee: yes
18:57:12 <gyee> I am more concern with reference implementations
18:57:19 <dolphm> alright, for the sake of completeness...
18:57:20 <dolphm> #topic high priority bugs or immediate issues?
18:57:30 <dolphm> we had a pair of bugs opened against admin API operations that weren't requiring *any* sort of auth
18:57:34 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1006815
18:57:36 <uvirtbot> Launchpad bug 1006815 in keystone "Admin API /v2.0/tenants/{tenant_id}/users/{user_id}/roles doesn't validate token" [Critical,In progress]
18:57:38 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1006822
18:57:40 <uvirtbot> Launchpad bug 1006822 in keystone "API(v2.0/OS-KSADM/services,v2.0/OS-KSADM/services/{service_id})doesn't validate token" [Critical,Fix committed]
18:57:44 <termie> services one is in
18:57:45 <ayoung> liemmn, is that a show stopper for you?  DO you need to deploy in "no certs allowed" environments?
18:58:18 <termie> ayoung: i wouldn't explicitly remove the old functionality just yet, for the record, but i think we probably want to deprecate it
18:58:20 <ayoung> that is not  right.  I just looked at /tenants/{tenant_id}
18:58:27 <ayoung> it confirms that an admin token was sent it
18:58:43 <ayoung> termie, how would it get configured?
18:58:48 <liemmn> ayoung:  I think Dolph answered my question... It is not a show stopper, but as a reference implementation, I would try to keep it as simple as possible.
18:59:05 <dolphm> and for more completeness, i'm going to assume there aren't any other high priority issues (i'm not aware of any, at least), and...
18:59:05 <dolphm> #topic open discussion
18:59:07 <ayoung> right not it is specified as a middle_ware
18:59:22 <ayoung> right now
18:59:27 <dolphm> and now we wait for mtaylor to dance us out of here
19:00:06 <termie> NOONTIME
19:00:19 <termie> well, in the real timezone
19:00:30 <termie> our meeting is now over, i think
19:00:34 <dolphm> true
19:00:35 <tongli|2> guys,
19:00:38 <termie> let's all run for the hills
19:00:41 <tongli|2> I have an item.
19:00:42 <ayoung> heh
19:00:47 <tongli|2> can we talk about it?
19:00:48 <termie> spit it out son
19:00:50 <dolphm> tongli|2: open discussion until mtaylor kicks us
19:00:54 <ayoung> tongli|2, fire away...we might get chased out soon
19:01:06 <tongli|2> Keystone log in with invalid tenant name return 200, should there be a difference between good and bad tenant name?
19:01:14 <tongli|2> I added into the agenda.
19:01:16 <dolphm> tongli|2: imo, yes, it should return a 401
19:01:21 <ayoung> agreed
19:01:28 <termie> sounds like it was already a bug?
19:01:31 <tongli|2> that bothers me a lot.
19:01:33 <mtaylor> dolphm: take your time, I doubt we have a full hour of stuff anyway
19:01:34 <dolphm> tongli|2: i'm pretty sure https://review.openstack.org/#/c/6875/ takes care of that (please test!)
19:01:48 <dolphm> mtaylor: i always think the same thing about keystone
19:02:00 <termie> i am in the middle of approving that patch
19:02:02 <mtaylor> dolphm: ++
19:02:03 <termie> FTR
19:02:08 <termie> unless i forget over lunch
19:02:16 <tongli|2> great. I will take a look at , thanks folks.
19:02:20 <dolphm> termie: i wouldn't blame you, lunch is awesome
19:02:22 <dolphm> in general
19:02:25 <dolphm> cool
19:02:28 <dolphm> #endmeeting