18:02:08 <dolphm> #startmeeting keystone
18:02:09 <openstack> Meeting started Tue Jun  4 18:02:08 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:12 <openstack> The meeting name has been set to 'keystone'
18:02:15 <dolphm> https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:24 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:43 <dolphm> #topic High priority bugs or immediate issues?
18:02:43 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1179955
18:02:45 <uvirtbot> Launchpad bug 1179955 in keystone "Disabling a tenant would not disable a user token" [Critical,In progress]
18:03:09 <ayoung> dolphm, so...just to point out
18:03:12 <dolphm> ayoung: that doesn't need to be in the meeting notes every week :P
18:03:16 <ayoung> this is a slippery slope
18:03:29 <dolphm> there's a few high priority bugs on our plate that we need to get backported to grizzly
18:03:37 <ayoung> I mean, we are not yet disabling projects
18:03:53 <dolphm> ayoung: sure we are
18:04:01 <ayoung> we meaning Keystone
18:04:10 <ayoung> we are not disabling the hyopervisors
18:04:16 <ayoung> or, the VMS rather
18:04:28 <dolphm> correct, that's a whole different issue tracked in bp notifications
18:04:49 <dolphm> https://blueprints.launchpad.net/keystone/+spec/notifications
18:04:51 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/notifications
18:05:06 <ayoung> but...we will need to be able to list tokens by project, which will be expensive, and not make termie happy
18:05:26 <bknudson> termie's been quiet lately
18:05:38 <ayoung> bknudson, day job has demanded his attention
18:06:26 <bknudson> should the project be in the token table/
18:06:52 <dolphm> regarding disabling tenants, we've had several related issues over the past 6 months regarding authz against disabled entities... we really need a framework to consistently handle the consequences of disabling/deleting any given entity
18:07:39 <henrynash_> dolphm: agreed, I think was a bit over zealous in the changes i made to grants/disabling/deletions etc.
18:07:42 <dolphm> performance has to come second to security related functionality... i think it's alright if disabling/deleting an entity is understood to be an expensive operation... we can fix performance later
18:08:04 <ayoung> dolphm, my suggestion is that we focus on short term tokens, and then the whole disable/revoke mechanism is not required.
18:08:40 <bknudson> we still have existing code out there that has to work.
18:08:42 <simo> ayoung: I guess you need to define short-term
18:08:58 <ayoung> simo, 5 minutes
18:09:21 <simo> ayoung: does that mean users need to renew credentials every 5 minutes ?
18:09:26 <ayoung> simo, within clock skew, the same amount of time for a change to propate through the system
18:09:45 <ayoung> simo, they will need a new token, yes
18:09:57 <simo> from a master token ?
18:10:03 <simo> or full re-authentication ?
18:10:14 <simo> what happens for requests that needs longer time ?
18:10:27 <dolphm> bknudson: project / domain, depending on scope
18:10:27 <dolphm> henrynash_: i think you made great progress in the right direction, but there's still some gaps to fill
18:10:27 <dolphm> i'd just like to make sure they're all filled so this is the last such defect we get
18:10:38 <ayoung> simo, later discussion
18:11:34 <henrynash> dolphm:  agreed..feel free to assign some of these to me to sfix if we think we need to
18:13:54 <henrynash> hmm…is the chat room misbehaving for others….I seem to get only bursts of messages every few minutes...
18:14:04 <bknudson> henrynash: working for me.
18:14:09 <henrynash> ok
18:14:27 <gyee> henrynash, I am having the same problem
18:14:33 <dolphm> henrynash: sure
18:14:57 <dolphm> two other reviews that simply need some love, as they're relatively high priority for backporting https://review.openstack.org/#/c/31552/ https://review.openstack.org/#/c/31559/
18:15:50 <topol> dolphm, I will review today. Will help me get back into the swing of things
18:15:53 <ayoung> approaved and ...
18:15:58 <dolphm> henrynash: that's happened to me w/ irc on poor wifi in the past
18:15:58 <dolphm> #topic Inherited roles from domain
18:15:58 <dolphm> #link https://review.openstack.org/#/c/29781/
18:15:58 <dolphm> henrynash: was this just on the agenda from last week?
18:16:08 <dolphm> topol: thanks
18:16:34 <henrynash> dolphm: yes, but I left it on since we've not managed to close it yet...
18:16:47 <gyee> I have two issues on that one
18:16:55 <henrynash> I went ahead and updated it as we discussed last week...
18:17:02 <gyee> 1) we need to extend the capability to all domains
18:17:05 <henrynash> but gyee and others have some legit concerns
18:17:16 <gyee> 2) one, instead of multiple, APIs to get the effective role grants
18:17:18 <dolphm> henrynash: anything worth discussing here, or just want more attention on the review?
18:17:43 <henrynash> so I think I'd like some guidance on the one vs multiple apis
18:17:50 <henrynash> (Gyee's 2nd point)
18:17:56 <henrynash> two choices:
18:18:42 <henrynash> a) extending, as is shown in the current proposal, various apis to support inherited roels
18:19:21 <henrynash> b) change the format of the grant call, to provide more or less terms to achieve this:
18:20:12 <henrynash> e.g. Role applicable to all projects within a domain
18:20:12 <henrynash> PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/projects
18:20:12 <henrynash> Roles inherited by all projects in all domains
18:20:12 <henrynash> PUT /usrs/{user_id}/roles/{role_id}/projects
18:20:12 <henrynash> Roles inherited by all domains, at the domain level
18:20:12 <henrynash> PUT /usrs/{user_id}/roles/{role_id}/domains
18:20:28 <gyee> I would like to see GET /user/{id}/roles return the effective grants, plus extra information on where the roles are granted
18:20:50 <ayoung> gyee, would "extrat info" be an additional call?
18:20:59 <henrynash> (which was Gyee's suggestion)
18:21:00 <gyee> ayoung, no
18:21:02 <henrynash> (so this is actually Gyee's 1st point, sort)
18:21:10 <ayoung> gyee, how would it look?
18:21:19 <gyee> it would be in the same collection
18:21:26 <gyee> just add an extra "scope" field or something
18:21:34 <henrynash> gyee: that's already in the spec…we just need to change the name slightly and implemt it as speced
18:21:42 <henrynash> (i.e. it's in the v3 spec!!!)
18:21:49 <dolphm> on point 1) i'd argue that global roles are completely out of scope for this change, HOWEVER, this change should be made with thought put towards what global roles would look like. global roles have been repeatedly poo-poo'd by the community since diablo
18:22:21 <gyee> dolphm, inherited is semi or not full global :)
18:22:27 <gyee> if not
18:22:38 <dolphm> gyee: henrynash: i think point 2 can be discussed better in review, with the context of the calls themselves?
18:22:39 <gyee> same use case
18:23:13 <gyee> role assignment is really about the scope it covers
18:23:25 <gyee> global, domain-global, domain-local, or project
18:23:27 <henrynash> dolphm: agreed
18:23:47 <gyee> that's essentially what "inherited" means
18:23:53 <gyee> really about role scoping
18:24:27 <henrynash> so "inherited" as I defined it is "domain-local" in your terminology?
18:24:32 <gyee> if we are going down the inherited path, we need something generic
18:24:48 <gyee> henrynash, it would be domain-global
18:24:55 <gyee> since it covers the entire domain
18:25:11 <gyee> domain-local is just domain grant without inheritance
18:25:13 <henrynash> gyee: ahh, so domain-local is what we have today for a domain role
18:25:20 <gyee> correct
18:26:21 <bknudson> can a role scope be both domain-local and domain-global?
18:26:23 <henrynash> do my argument agains global is simply that .given that domain creation is either a rare occurrence (which case adding a role to each domain is not a chore) or frequent and automated (in which case automation could do the role assignment) - is the lack of global role really that bad?
18:26:35 <topol> would help to somewhere clearly define domain-local, domain-global, etc.
18:26:46 <gyee> bknudson, if we want, my point is we need something generic so we can extend later if we want
18:27:16 <ayoung> what is the distinction between domain-global and domain-local?
18:27:31 <gyee> domain-global = inherited by all projects
18:27:38 <gyee> domain-local = domain only
18:27:48 <simo> better nming perhaps: global-scope, domain-scope, project-scope
18:27:55 <ayoung> ok, can we not call it domain-global
18:28:00 <topol> simo +1
18:28:03 <ayoung> simo, +1
18:28:07 <gyee> simo, that's fine, we can make the names more intuitive
18:28:16 <gyee> but we need something extensible
18:28:19 <simo> gyee: it' half the work, really :)
18:28:20 <gyee> and generic
18:28:43 <simo> dolphm: may I raise a concern ?
18:28:58 <simo> maybe it's my lack of knowledge though
18:29:02 <ayoung> so...isn't this really a mapping issue
18:29:18 <ayoung> users in Group X get a role on all projects in domain Y
18:29:26 <henrynash> gyee: so your argument is that the api changes should allow a progression to more globalness in the  future if we chose that path?
18:29:45 <gyee> henrynash, correct
18:30:25 <henrynash> gyee: Ok, understand that
18:31:26 <ayoung> So...dchadwick would, if he were here, point out that this is just the sort of problem the mapping code is supposed to solve
18:31:41 <simo> ayoung: it is possible
18:31:42 <ayoung> maybe we should punt on this until we have a plan to get that integrated instead
18:31:46 <gyee> ayoung, mapping is a different issue I think
18:31:53 <ayoung> gyee, mapping is a mechanism
18:31:58 <simo> ayoung: is there a concept of groups in keystone currently ?
18:32:01 <henrynash> ayoung: it's rally how we express that various mappings we want (or might want)
18:32:01 <henrynash> gyee: so you would be ok if we didn't go all the way to "global", but the api changes we make would allow us a natural progression to that in the future if we chose it?
18:32:03 <ayoung> simo, yes
18:32:07 <gyee> mapping is name manipulation
18:32:13 <simo> ayoung: what for ? I can't think of why you would want it
18:32:42 <ayoung> gyee, mapping is "attribute in"  becomes "Attribute out"
18:32:50 <gyee> henrynash, as long as we make it generic and extensible, I am fine
18:33:00 <ayoung> gyee,  "attribute out" in this case would be "role in project"
18:33:00 <simo> aren't projects sufficient ?
18:33:08 <ayoung> simo, nope
18:33:19 <ayoung> projects are the groupsing for external resources
18:33:24 <henrynash> gyee: ok, let me work on that and update the bp
18:33:26 <ayoung> groups are like LDAP groups for users
18:33:27 <gyee> ayoung, role is just a name today
18:33:31 <gyee> nothing more
18:33:42 <ayoung> gyee, it is the inheritance thing that mapping solves
18:33:50 <ayoung> the mechanism for assigning implicit roles
18:34:00 <simo> you know the concern I have is that it seem we have nowhere a document that describes the security model and all the security/identity elements in the system and what they are intended to be used for
18:34:11 <simo> this means everyone will have their own ideas about things
18:34:21 <simo> and there will be friction implementing any change
18:34:27 <gyee> ayoung, role manipulation can be done in the pluggable token provider if you want :)
18:34:30 <henrynash> dolphm: ok, maybe time for  another topic…I still 20 mins
18:34:38 <henrynash> (I stole 20 mins)
18:34:46 <gyee> that's where we pull all the roles and stuff them into token
18:34:47 <ayoung> gyee, mapping is the mechanism for implementing
18:34:55 <ayoung> so, yes
18:35:12 <ayoung> simo, you had an issue with the service catalog
18:35:21 <simo> well sort of
18:35:21 <ayoung> you need to get an endpoint out, but don't jhave a token
18:35:32 <ayoung> and right now we say that is "admin only"
18:35:32 <simo> I think that's a big dicussion and I gave up on it for now
18:35:44 <ayoung> dolphm, is there any reason to "protect" the service catalog?
18:35:51 <simo> but the quesiton I have is why read access to the catalog is restricted ?
18:35:59 <gyee> yeah, we need an interface for service catalogs, similar to AccessInfo
18:36:06 <gyee> perhaps it can lives in oslo
18:36:12 <simo> oslo ?
18:36:13 <ayoung> simo, I do know that it is supposed to be scoped to give the user the "right" service catalog
18:36:23 <simo> gyee: you mean as a client ?
18:36:24 <ayoung> simo, oslo is openstack common
18:36:29 <simo> ayoung: I know
18:36:36 <bknudson> all data from Keystone should be protected by ssl
18:36:36 <simo> (found out :)
18:36:41 <gyee> right, we need a consistent way for clients to access the service catalog
18:36:50 <simo> bknudson: ?
18:36:52 <gyee> parse and access
18:37:07 <ayoung> gyee, so the question is do we need to protect the query for endpoints?
18:37:20 <simo> bknudson: unless you are talking ssl client certs, ssl does not 'protect' much, on its own
18:37:35 <gyee> ayoung, sure, that's what endpoint-filter bp's about
18:37:38 <ayoung> I would think that, at a minimum, we should drop the "admin is required" on querying the service catalog
18:37:59 <simo> gyee: is there any place that explains why the catalog must be secret?
18:38:12 <gyee> https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering
18:38:15 <ayoung> gyee, yeah, but I was think that was what we put in the token.  But maybe direct query of all endpoints for a service would be exposing too much info?
18:38:19 <dolphm> (i'll take that as a yes)
18:38:19 <dolphm> #topic DB2 enablement
18:38:19 <dolphm> #link https://wiki.openstack.org/wiki/DB2Enablement
18:38:19 <dolphm> bknudson: all yours
18:38:21 <simo> what is the point in withholding information about endpoints ?
18:38:30 <bknudson> this should be a quick one...
18:38:45 <bknudson> others here have been working with the community to set up DB2 test env
18:39:01 <bknudson> we have some docs up on the wiki now: https://wiki.openstack.org/wiki/DB2Enablement
18:39:19 <bknudson> that I've asked the guy who wrote it here to update with more detailed instructions for those not familiar with db2
18:39:21 <gyee> simo, what's the point of returning an endpoint you don't have access to?
18:39:30 <bknudson> we had a blueprint https://blueprints.launchpad.net/keystone/+spec/db2-database that was closed
18:39:37 <simo> gyee: (define you)
18:39:46 <bknudson> and it seemed like the correct way to proceed was to file a bug and submit the code
18:39:48 <ayoung> bknudson, so, my position is the same as before:  we should make sure thatthe generic DB code executes the same on all platforms.  THat requires getting the DB code into gate first and foremost
18:39:49 <gyee> you = token holder
18:39:50 <bknudson> so that's what I plan to do
18:40:07 <simo> gyee: in my case I do not even have a token (and don't need one for now)
18:40:44 <ayoung> bknudson, so the issue is provisiong the DB for testing, and it sounds like tempest is the right place to do that.  Ideally, the Postgresql and DB2 code paths would be identical
18:40:46 <bknudson> ayoung: I agree it would be great to have it in the gate.
18:41:30 <bknudson> ayoung: I thought even the postgres testing was out of the gate since nobody was supporting it?
18:41:35 <dolphm> (i got booted by freenode)
18:41:42 <simo> bknudson: I use it every day :)
18:42:03 <simo> dolphm: seem there are issues on freenode today
18:42:04 <ayoung> bknudson, for now, you can add a config file in test so that we can run the migrations against DB2, and we'll work on getting the rest of the backend tests running against the real RDBMSs afterwards
18:42:07 <dolphm> simo: are you supporting it?
18:42:09 <gyee> sure, lets include DB2
18:42:12 <ayoung> dolphm, yes we are
18:42:16 <bknudson> ayoung: easy to do.
18:42:17 <simo> dolphm: you got booted for 'excess flood'
18:42:19 <gyee> more tests more merrier
18:42:23 <ayoung> DB2 won't go into gate, though
18:42:44 <ayoung> That can be your companies Special sauce, bknudson
18:42:49 <dolphm> simo: postgres gate is failing
18:42:57 <bknudson> http://logs.openstack.org/31559/2/check/gate-tempest-devstack-vm-postgres-full/20047 : FAILURE in 53m 03s (non-voting)
18:43:08 <dolphm> ayoung: or ibm can donate CI resources to make it a gate
18:43:10 <simo> tbh I find it a bit ridiculous we need to have more and more and more DBs ...
18:43:16 <gyee> bknudson, does DB2 need to be open sauce first?
18:43:28 <simo> dolphm: I and ayoung will make sure someone takes a look
18:43:29 <dolphm> simo: agree, but there's not one db that fits all
18:43:42 <simo> dolphm: it needs to fit US! right ?
18:43:52 <dolphm> simo: everyone's deployment is different
18:43:58 <simo> sigh
18:44:03 <dolphm> agree
18:44:27 <bknudson> gyee: I guess it's up to the community if they will accept code changes to support a non-open-source db.
18:44:30 <simo> dolphm: it's just a slow down, crappy inducing factor, but I do understand, for once I can;t stand mysql :)
18:44:44 <dolphm> simo: agree
18:45:01 <dolphm> gyee: depends on the extent of the changes :(
18:45:04 <dolphm> bknudson: *
18:45:05 <gyee> knudson, should this be a legal discussion first?
18:45:20 <dolphm> bknudson: if you need proprietary support, then it's tough odds
18:45:23 <simo> do we have db specific code actually ?
18:45:33 <simo> isn't everythign wrapped into sqlalchemy ?
18:45:40 <dolphm> bknudson: if you're simply discovering issues using db2 that benefit other backends, then great
18:45:49 <dolphm> simo: migrations, typically
18:45:54 <bknudson> simo: there are several places where we've got db-specific code in migrations.
18:45:58 <gyee> simo, problem is sqlalchemy behave differently for different dbs
18:46:09 <gyee> that's why more tests is good
18:46:12 <bknudson> the changes I've got to support db2 are similar to the ones for mysql/postgres/sqlite.
18:46:14 <simo> gyee: well of course, given different DBs have different features ...
18:47:09 <gyee> simo, no, I mean basic stuff like renaming a table
18:47:14 <ayoung> bknudson, yeah...on that point
18:47:14 <gyee> some support it some don't
18:47:21 <dolphm> bknudson: feel free to put them up for review
18:47:23 <simo> dolphm: wouldn't it be beneficial at least to try to confine all 'special' code into a pluggable module ?
18:47:29 <ayoung> https://review.openstack.org/#/c/31249/  is not longer DB specific
18:47:33 <bknudson> dolphm: ok, I'll try it.
18:47:39 <dolphm> simo: migrations can be broken down that way already
18:47:44 <simo> gyee: in fact renaming tables is a 'feature' :-/
18:47:56 <bknudson> ayoung: I think https://review.openstack.org/#/c/31249/ is a good example where db2 support might be helpful.
18:48:32 <ayoung> bknudson, try running the Postgresl live tests against DB2 and post your results
18:48:35 <bknudson> the mysql fix was specific to mysql whereas this one should work with db2.
18:48:56 <bknudson> I'll give it a try
18:49:10 <ayoung> bknudson, you should be able to modify the test config for DB2 and run
18:49:38 <ayoung> So...one issue on splitting identity if we have time?
18:50:24 <ayoung> I wrote it up as Mapping Usernames from Multiple IdP's to Keystone
18:50:29 <ayoung> and sent it in email
18:50:45 <ayoung> #link https://etherpad.openstack.org/mapping-user-ids
18:51:13 <dolphm> (fyi, i'm going to #endmeeting a bit early)
18:51:13 <ayoung> jamielennox, dchadwick/ksiu and I have be debating this one, and I wanted to get a larger perspective
18:51:46 <gyee> ayoung, I'll take a look
18:51:48 <ayoung> I think I want to drop the "expires" time thing from the user bp
18:51:49 <gyee> on my todo list
18:52:01 <gyee> +1 on dropping expires
18:52:03 <ayoung> it seems to me that it should be role assignments which are time limited
18:52:15 <gyee> nope
18:52:27 <gyee> role assignments shouldn't have a time limit either
18:52:36 <dolphm> #topic open discussion
18:52:36 <mordred> fwiw - I don't think there are any problems adding db2 support patches - but it's unlikely that the CI systems will be able to test them for you
18:52:38 <gyee> that's strictly a backend/provider issue
18:52:39 <ayoung> gyee, true, it can be enforced by token expiriy
18:53:03 <ayoung> gyee, this is for autoprovisioning
18:53:31 <dolphm> bknudson: mordred: nor does the community necessarily have the expertise to properly review them
18:53:45 <mordred> dolphm: ++
18:53:54 <ayoung> So, what we need is a policy that enforces the token creation, but we don't need expl;icit APIs for them.
18:54:02 <gyee> ayoung, not sure what you mean
18:54:09 <ayoung> gyee, I am agreeing with you
18:54:23 <gyee> how does token expiry related to role expiry?
18:54:42 <bknudson> dolphm: I think we'll have ci infra internally here, so I'll probably post a fix if it breaks.
18:54:43 <ayoung> gyee, think of it as "on demand you get a limited amount of resources for a limited time"
18:55:03 <gyee> btw, my colleague is ready to work on the generic signature auth bp
18:55:10 <gyee> #link https://blueprints.launchpad.net/keystone/+spec/generic-signature-validation
18:55:15 <gyee> my colleague Nachi
18:55:27 <gyee> if you guys have some time, please review the proposal
18:55:31 <ayoung> gyee, that is kindof what simo is working on, isn't it?
18:55:36 <dolphm> bp temporary-user-provisioning can certainly be done as an extension - it doesn't need to be done as core
18:55:47 <gyee> dolphm, +1
18:55:55 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/temporary-user-provisioning
18:55:59 <gyee> ayoung, no, that's different
18:56:16 <gyee> I think simo is working on the kerberos stuff
18:56:22 <ayoung> dolphm, agreed, and I think we don't need to expand the API to support it, the more I think about it, the more I am convinced it can be handled  with current public APIs
18:56:36 <ayoung> gyee, no, he is doing the messaging crypto stuff
18:56:44 <ayoung> which includes HMAC
18:56:47 <simo> gyee: no I am doing message signing
18:57:05 <gyee> ok, we're good then
18:57:25 <simo> gyee: and I have a patch in oslo-incubator that will give you access to generic HMAc as part of my bp
18:57:33 <simo> gyee: so let's try not to duplicate work
18:57:33 <ayoung> simo, I thought you were doing HMAC as part of that?
18:57:45 <simo> what I said precisely
18:57:48 <gyee> simo, beautiful
18:57:52 <ayoung> yes, you type faster than I do
18:57:59 <gyee> we can definitely leverage your stuff
18:58:21 <simo> gyee: please tell your colleague to review https://review.openstack.org/#/c/28471/
18:58:29 <simo> gyee: and let me know if he needs anything else
18:58:58 <dolphm> just a couple minutes left, but i'd suggest switching to -dev :)
18:58:59 <dolphm> #endmeeting