18:01:50 <dolphm> #startmeeting keystone
18:01:51 <openstack> Meeting started Tue Jun 11 18:01:50 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:55 <openstack> The meeting name has been set to 'keystone'
18:02:03 <dolphm> #topic Havana milestone 2 cut & API-level feature freeze July 16th
18:02:06 <topol> who remembers those I cant believe its not butter commercials with Fabio?
18:02:11 <dolphm> #link https://wiki.openstack.org/wiki/Havana_Release_Schedule
18:02:36 <dolphm> just a reminder that api-impacting things need to land this milestone
18:02:54 <dolphm> so, get on identity-api reviews asap :D
18:03:08 <dolphm> #topic High priority bugs or immediate issues?
18:03:16 <topol> dolphm, you have a link?
18:03:38 <dolphm> topol: https://review.openstack.org/#/q/project:openstack/identity-api+status:open,n,z
18:03:38 <topol> for identity-api reviews
18:03:44 <topol> thanks
18:04:00 <dolphm> bug 1179955 is still outstanding
18:04:01 <uvirtbot> Launchpad bug 1179955 in keystone "Disabling a tenant would not disable a user token" [Critical,In progress] https://launchpad.net/bugs/1179955
18:04:08 <gyee> was hoping to get a resolution on the inherited role stuff
18:04:13 <dolphm> it's marked in progress and assigned to me, but i'll i've done is put up tests WIP
18:04:28 <henrynash> gyee: on the agenda later
18:05:07 <henrynash> dolphm: what needs doing …the actual fix?
18:05:18 <dolphm> henrynash: yeah
18:05:38 <dolphm> henrynash: we should probably do a simple fix asap, but i'd like to take a long hard look at the overall problem and do a lot of refactoring
18:06:00 <dolphm> if anyone wants to put up a fix, feel free, otherwise i'm sure i'll get to it in a couple days
18:06:05 <dolphm> i'm not aware of any other big issues that need attention, so...
18:06:12 <dolphm> #topic Changing the default token backend from KVS to SQL or Memcache
18:06:17 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1188370
18:06:19 <uvirtbot> Launchpad bug 1188370 in keystone "kvs driver for tokens is not a production quality default" [Low,In progress]
18:06:24 <dolphm> #link https://review.openstack.org/#/c/32296/
18:06:43 <topol> dolphm, I htought Memcache was the only one that really scales
18:06:50 <dolphm> henrynash commented in the above review that we should also consider memcache as a viable default option
18:07:02 <topol> +1
18:07:05 <morganfainberg> topol: memcache does scale better, thought, it has some issues.
18:07:05 <henrynash> I think we all agree kvs is not the right one
18:07:15 <bknudson> we should have at least one token backend that's production quality
18:07:28 <dolphm> topol: both are better than kvs :)
18:07:29 <topol> SQL makes us look bad when under stress :-)
18:07:39 <bknudson> maybe we need a note regarding each backend the quality, production or not
18:07:40 <henrynash> is PKI the default on the client now?
18:07:52 <dolphm> henrynash: ?
18:07:57 <topol> PKI??
18:08:07 <dolphm> bknudson: kvs backends are raelly intended to be undocumented / for dev
18:08:07 <henrynash> for tokens
18:08:17 <dolphm> henrynash: what does the client care?
18:08:18 <bknudson> PKI is a server setting
18:08:21 <henrynash> (instead of UUID)
18:08:32 <bknudson> client knows how to handle PKI or UUID
18:08:33 <topol> PKI is default on server side
18:08:46 <bknudson> (correct me if I'm wrong)
18:08:58 <morganfainberg> bknudson: that is my understanding
18:09:28 <bknudson> does memcache require any extra packages / server started?
18:09:33 <henrynash> …in which case this (I think) would make the performance of memcache vs SQL somewhat mute…(since the token can be validate in the auth_token middleware
18:09:37 <bknudson> nice thing about kvs is it doesn't require any config
18:09:43 <morganfainberg> bknudson: it requires the python-memcache client, and the memcache server
18:09:46 <morganfainberg> running.
18:09:53 <dolphm> morganfainberg: ++
18:10:14 <morganfainberg> SQL is probably the best default since the identity drive defaults to SQL.
18:10:16 <topol> arent those typically there?
18:10:25 <henrynash> and the only issue is the built up of records due to us not having any auto-cleanup of expired tokens by default
18:10:26 <morganfainberg> topol: the python-memcache package, yes.
18:10:40 <bknudson> I assume someone would have db setup for another backend (identity), so they'd already have it setup.
18:10:48 <morganfainberg> bknudson: yep.
18:11:05 <bknudson> so I'd lean towards sql.
18:11:23 <henrynash> bknudson: my issue is that if we do that, by default, the DB will fill for ever
18:11:33 <topol> So SQL does not do well under stress.  So you will get a lot of bug reports where you end up recommending memcache to handle the load
18:11:36 <dolphm> henrynash: we have keystone-manage token_flush now
18:12:03 <henrynash> dolphm: true…I assume that is a manual operation (by default)
18:12:06 <bknudson> devstack must set the token backend to sql.
18:12:09 <morganfainberg> I am also working on some retro-fitting of the revocation lists, which will include (if I can make it happy) cleanup options
18:12:34 <bknudson> morganfainberg: for sql or memcache?
18:12:49 <morganfainberg> bknudson: the revocation list cacheing BP will encompass all revocation lists
18:13:03 <morganfainberg> i'm planning on making it have semantics to cleanup SQL if enabled.
18:13:20 <morganfainberg> again, provided I can do it cleanly
18:13:30 <bknudson> had we discussed before not providing so many tokens?
18:13:37 <topol> I would recommend that we convince ourselves that SQL wont fill up anymore before it becomes the default
18:13:42 <bknudson> this is kind of the root of the problem
18:13:50 <dolphm> i think the best first step is to switch to sql as a default, and then have the "should we switch to memcache" as a default after that
18:14:02 <gyee> +1
18:14:04 <morganfainberg> that is the end-all solution, but we need to be tolerant of people issuing a ton of tokens.
18:14:20 <dolphm> ... have that *conversation* later
18:14:33 <morganfainberg> +1 to what dolphm said
18:14:42 <dolphm> topol: it will fill up just as kvs does
18:14:53 <dolphm> topol: so, it's not a worse solution than kvs in that respect
18:15:00 <bknudson> I have no problem with sql as the default.
18:15:03 <topol> dolphm, agreed.
18:15:07 <henrynash> dolphm: Ok, agreed…let's do that
18:15:22 <dolphm> cool
18:15:28 <dolphm> #topic Push to complete role-assignment/inheritance api changes
18:15:48 <henrynash> so this is just a call to get any final comments into these bps…links coming up...
18:15:55 <dolphm> #link https://review.openstack.org/#/c/29781/
18:16:10 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles
18:16:18 <henrynash> thx :-)
18:16:30 <gyee> "scope" is more extensible
18:16:43 <bknudson> so now roles have attributes
18:16:47 <bknudson> and aren't just names
18:16:52 <dolphm> i haven't caught up to this conversation since thursday/friday..
18:17:11 <topol> I knew I would something important while on vacation...
18:17:13 <henrynash> So roles give guidance as to how inheritance should work WHEN they get assigned
18:17:48 <henrynash> For everyone's info:
18:18:06 <henrynash> the current proposal only covers inheriting from a domain to its projects
18:18:21 <gyee> today role definition is just a name, nothing more
18:18:43 <dolphm> gyee: for consumers, that won't change
18:18:47 <dolphm> correct?
18:18:48 <henrynash> gyee and others would also like more global roles across all domains…What I have proposed (read the various comments) can be extended for that
18:19:11 <henrynash> I am suggesting we put that extension into a separate proposal
18:19:17 <gyee> dolphm, right, unless we change the policies
18:19:43 <dolphm> don't want to impact anyone on this
18:19:46 <henrynash> gyee: the point about "scope" vs booleans…..
18:19:52 <gyee> role assignment is really about the scope in which the role is "applicable"
18:20:11 <gyee> boolean is not extensible
18:20:49 <bknudson> I generally agree that booleans are a bad idea where an enum would be more descriptive.
18:20:52 <henrynash> gyee: we need to have distinctions between how to apply role assignments to both domains and and projects….As per my comments, we would add a second boolean for "inherted_to_domains"…since you need all 4 states
18:21:02 <dolphm> gyee: is there an extensibility scenario you have in mind that you didn't suggest in the code review? henrynash seems to address your concerns pretty well
18:21:21 <gyee> henrynash, we don't want to keep adding booleans
18:21:56 <gyee> so tomorrow we want to support othe scopes, we are going to keep adding boolean?
18:22:02 <henrynash> gyee: we either have two booleans or all 4 states in the enum
18:22:12 <bknudson> http://codeclimber.net.nz/archive/2012/11/19/Why-you-should-never-use-a-boolean-field-use-an.aspx
18:22:13 <gyee> that would be very confusing would it
18:22:21 <gyee> having to aggregate the two or more
18:22:51 <gyee> bknudson, agreed 110%, booleans are bad for multistate
18:22:59 <dolphm> gyee: the meaning of your enumerations was obviously a source of confusion in the last keystone meeting
18:23:07 <fabio> +1 bknudson
18:23:20 <dolphm> gyee: perhaps there are more intuitive terms we can use, but that's my *only* opposition to your proposal
18:23:24 <henrynash> gyee: my concern is if they are independant concepts, then is an 8 role enum better than 3 booleans?
18:23:32 <gyee> dolphm, I am fine with different naming
18:23:39 <gyee> but I am not fine with boolean
18:24:27 <henrynash> gyee, dolphm: Ok, I'll document both alreatnatives in a email tonight…and I'll look to response by tomorrow…then we'll make the call
18:24:36 <bknudson> if it turns out that the names aren't adequate maybe we go to a structure (object), or maybe we add another field.
18:24:38 <bknudson> Either way, I
18:24:47 <bknudson> I'd prefer names over true/false.
18:24:55 <gyee> I am fine with either a structure, enum, or string
18:24:57 <gyee> but not boolean
18:25:09 <dolphm> gyee: what's the fundamental opposition to booleans?
18:25:27 <gyee> dolphm, role scope is multi-state
18:25:52 <gyee> you don't want to use multiple booleans to describe multiple states
18:26:13 <dolphm> i really don't want to see things like 'inherits-to-projects-but-not-if-assigned-to-a-group-on-tuesdays' in the enumeration to handle dumb edge cases
18:26:32 <gyee> enum or string gives us a lot of flexibility
18:27:01 <henrynash> right now we'd have (something like)
18:27:06 <dolphm> gyee: is there some scenario you have in mind that you're designing for beyond the 4 states we're currently discussing?
18:27:12 <atiwari> I also see an issue with defining global behavior in roleDef
18:27:33 <henrynash> inherited_to_projects, inherited_to_domains, Inhertited_to_projects_and_domains
18:27:43 <gyee> dolphm, and you want to represent 4 states in a boolean?
18:27:45 <dolphm> atiwari: +1 that's a weird one, because the assignment of a 'global' role to a specific project or domain doesn't make any sense
18:27:50 <atiwari> we have to define multiple roleDefs and which will make complexity in policy
18:28:14 <gyee> atiwari, policies act on role names
18:28:27 <gyee> it doesn't care about the mechanism in which the role is obtain
18:28:28 <dolphm> gyee: he's saying he'd have to radically expand the number of role names he's using in policy
18:28:38 <atiwari> that is true but think of one Nova role e.g. sys-admin
18:28:38 <gyee> we are talking about the mechanism to assign roles
18:28:58 <dolphm> 'admin' will have to become 'global-admin' 'domain-admin' and 'project-admin'
18:29:02 <atiwari> how do we fit that for global and domain-global use case
18:29:05 <gyee> atiwari, its more scarier than that :)
18:29:15 <henrynash> atiwari: we are not defining any kind of global behaviour in the role itself….only how that role is inherited (or not) form the point of assignment
18:29:21 <gyee> role definitions are not tied to services
18:29:33 <gyee> you have to name your role different to avoid conflicts
18:29:33 <topol> do we have the notion of a global-admin (ie super-admin) yet?
18:29:59 <dolphm> henrynash: changing the semantics of how a role can be applied (defining it to be 'global' in scope) has direct impact on the way that role can be intuitively assigned
18:30:14 <gyee> say you have an "admin" role, how can you tell its really a nova admin or swift admin?
18:30:17 <bknudson> henrynash: the inherited_by_projects property only has an effect at the time of assignment, so that if I change the value, no existing assignments are affected?
18:30:30 <bknudson> (which is different than a previous revision of the design)
18:30:33 <dolphm> henrynash: PUT /projects/{project_id}/users/{user_id}/roles/{some_global_role} suddenly doesn't make sense
18:30:37 <henrynash> dolphm: which is why we don't use the term "global" anywhere
18:30:43 <dolphm> yet
18:30:51 <atiwari> gyee that is another issue which need some attention the serviceId
18:30:54 <henrynash> dolphm: and I'm not suggesting we ever dp
18:30:56 <henrynash> do
18:31:06 <gyee> atiwari, absolutely
18:31:07 <dolphm> henrynash: i know :)
18:31:14 <henrynash> what we *might* do is add a iinherited_to_domains flag in the role...
18:31:37 <atiwari> roleDef without a serviceId is complex to handle
18:31:47 <gyee> inherited by projects is essentially "global" within a domain, no?
18:32:07 <henrynash> and then if you applied (using an api that doesn't exist today) PUT /dmains/*/roles/roleId/users/userId
18:32:07 <atiwari> and we ahev to make the role name unique all over the services
18:32:13 <dolphm> gyee: that's not global at all, according to your definition of global
18:32:13 <atiwari> have
18:32:29 <gyee> dolphm, global and domain-global
18:32:44 <henrynash> gyee: there are just too confusing
18:32:47 <dolphm> gyee: do you get 'global' roles along with an unscoped token?
18:32:53 <gyee> global - applicable to all projects and all domains, regardless of token scope
18:33:36 <gyee> dolphm, global yes, domain-global no
18:33:39 <henrynash> gyee, dolphm: give me the floor here for 3 mins
18:33:59 <topol> didnt we have a similar conversation last week???
18:34:13 <atiwari> henrynash: I think we need to think through a use case to support global as well as domain-global roleDef for the similar capability
18:34:21 <henrynash> the things we add to roledef should just indicate HOW we inherit (or not) roles when they are assugned
18:34:26 <henrynash> so
18:34:33 <atiwari> and I can see that we will endup with complex policy
18:35:02 <henrynash> inherit_to_projects means….IF you assign this role to a domain, it will be interpreted as being inherited to any projects within it
18:35:34 <atiwari> I think inheritence should be enforced in the role assignment
18:35:35 <henrynash> imagine we add inherit_to_domains as another options (via enum or whatever) to roeldef
18:35:41 <henrynash> then
18:36:05 <henrynash> IF you can assign just a role to a "root" domain, then all child domains would inherit that role
18:36:31 <henrynash> if we ever supported nested domains, only the one below the assignment point would inherit the roles
18:36:54 <atiwari> think you need same capabilty for a global and domain-global roleDef
18:37:04 <atiwari> you can not get that with single roleDef
18:37:09 <henrynash> the missing piece(for inherit_to_domains) would be to amend the assignment API to someone specify "the root" domain
18:37:21 <henrynash> </henry>
18:37:25 <atiwari> you have to define multiple roleDefs and hence policy
18:37:26 <dolphm> henrynash: aaand, you've sold me on booleans
18:37:31 <topol> henrynash  why would all levels of nested domains inherit the role???
18:37:44 <dolphm> topol: because inherit_to_domains=true
18:37:44 <topol> err why wouldnt?
18:37:55 <henrynash> topol: (hyperthetcially) …onlythose domains in the tree below the assignment point
18:38:10 <topol> but multiple levels deep, correct?
18:38:16 <henrynash> topol: yes
18:38:21 <topol> k, im good then
18:38:27 <dolphm> i like how subdomains are suddenly on the table again lol
18:38:34 <henrynash> topol: not that we have sub domains yet
18:38:51 <topol> understood. just for my own understanding
18:38:55 <henrynash> dolphm: I'm not pushing for them, just wanted a solution that would work with them
18:39:05 <dolphm> henrynash: i appreciate that
18:39:06 <gyee> henrynash, so you are proposing one boolean "inherited_to_domains" as oppose to "inherited_by_projects"?
18:39:13 <gyee> not sure if I understand you
18:39:13 <dolphm> gyee: both
18:39:19 <henrynash> gyee: no, tow booleans
18:39:32 <henrynash> inherited_to_domains, and
18:39:33 <dolphm> gyee: inherited_by_projects today, the other tomorrow
18:39:37 <henrynash> inherited_to_projects
18:39:48 <topol> I actually find the booleans easy to understand.
18:39:52 <gyee> and they are both mutually exclusive?
18:39:53 <dolphm> topol: +1
18:39:56 <bknudson> how about { "inherited": { "domains": true, "projects": true } }
18:40:00 <henrynash> gyee: no
18:40:09 <dolphm> topol: i share you confusion with the enumerations
18:40:16 <atiwari> gyee +1
18:40:16 <henrynash> bknudson: I'm ok with taht
18:40:42 <topol> cause if we have a hard time undersat5nding the semantics our stakeholders will forever send us bug reports
18:40:46 <henrynash> I actually wanted to call them "apply_to_child_projects"
18:40:52 <dolphm> topol: +1
18:40:55 <henrynash> "apply_to_child_domains"
18:41:09 <henrynash> but thought that child wasn't real a term we use
18:41:19 <fabio> bknudson: you don't even need the boolean, you can just have a list
18:41:39 <topol> what was wrong with inherited _to_domains and inherited_to_projects???
18:41:45 <bknudson> { "inherited": ["domains", "projects"] }
18:41:55 <gyee> what happen if "domains": true, "projects": false?
18:41:58 <fabio> yes
18:42:05 <gyee> or the other way around?
18:42:05 <fabio> in this way is extensible
18:42:11 <dolphm> i think i prefer to individual booleans over the structure
18:42:13 <fabio> you can add new concepts
18:42:21 <henrynash> gyee; roles sit on the domain, don't get to the projects
18:42:30 <dolphm> fabio: did you just miss the last 20 minutes of conversation?
18:42:43 <fabio> no I did not
18:42:51 <fabio> why do you have to say project = true
18:43:01 <fabio> if project is in the list it means it inherits from it
18:43:22 <henrynash> fabio: means it gets inherited to
18:43:32 <atiwari> are we still thinking of having inheritable in roleDef?
18:44:10 <henrynash> which is kind of why I like the more descriptive booleans…."inherited_to_projects" or "apply_to_child_projects"...
18:44:19 <henrynash> atiware: this is all about the roelDef
18:44:39 <dolphm> henrynash: +1
18:45:13 <henrynash> but { "inherited to": ["domains", "projects"] } would be your view bknudson?
18:45:46 <gyee> henrynash, that's would be the enum approach we talked about earlier
18:45:47 <bknudson> henrynash: yes, this would remove duplication
18:45:56 <atiwari> henrynash: I think we are not seeing the problem with this approach
18:46:20 <gyee> I am down with the enum approach
18:46:23 <gyee> less confusion
18:46:27 <gyee> and extensible
18:46:36 <dolphm> gyee: more* confusion
18:46:38 <fabio> I agree with bknudson
18:46:42 <dolphm> gyee: just as extensible*
18:47:02 <gyee> dolphm, keep adding boolean as extension?
18:47:15 <topol> +1 on the booleans
18:47:25 <dolphm> gyee: sure, or add an enumeration on top of that if you find a use case that booleans don't work for
18:47:34 <bknudson> even with booleans it's not like we can't change it to a string/enum later.
18:47:39 <bknudson> that's the power of JSON
18:47:41 <dolphm> gyee: booleans solve the current use cases
18:48:26 <atiwari> once we set a roleDef with any inheritance behavior that roleDef is used only for that.
18:48:48 <atiwari> and we have to define multiple roleDefs for the same purpose
18:49:09 <gyee> dolphm, he's use case is cloud provider version admin
18:49:15 <gyee> that's applicable to all the domains
18:49:26 <gyee> versus admin
18:49:31 <henrynash> so let's finish the booleans discussion
18:49:52 <henrynash> I think  the general agreement is two booelans or { "inherited to": ["domains", "projects"] }
18:50:12 <topol> +2 on the booleans..  (I will keeep upping the ante)
18:50:16 <gyee> henrynash, that looks like an enum
18:50:26 <gyee> { "inherited to": ["domains", "projects"] }
18:50:49 <atiwari> -2 with this approach
18:51:05 <henrynash> atiwari which? { "inherited to": ["domains", "projects"] }
18:51:13 <topol> atiwari, which approach?
18:51:30 <atiwari> having this info in roleDef
18:52:24 <henrynash> dolphm: suggest we rule for two booleans for now
18:52:41 <dolphm> +1
18:52:51 <henrynash> atwari: happy to take it off line and discuss your conerns
18:52:52 <atiwari> This would cause role explosion and policy complexity.
18:52:52 <topol> agreed, until we have use cases that show two booleans wont work
18:53:03 <topol> (if ever)
18:53:13 <bknudson> I thought rbac already had a problem with role explosion?
18:53:21 <dolphm> atiwari: i don't see how the other model is any different in that respect
18:53:33 <gyee> I need some clarification
18:53:41 <gyee> are we going with this? { "inherited to": ["domains", "projects"] }
18:53:49 <henrynash> atiwari: so that was my INITIAL concern over using try roleDef, but the general consensus was that was better than changing the apis to include inheritance as parameters
18:53:58 <topol> why isnt this scenario fairly contained for what henerynash is trying to accomplish? For more complex stuff we may add somethig else, vcorrect?
18:54:05 <atiwari> but this approach wd cause even more explosion
18:54:35 <dolphm> topol: +1, i just want to make sure we're not screwing ourselves over on future use cases
18:54:38 <atiwari> sorry I did not see the issue that time
18:55:05 <atiwari> and now it seems totally wrong to me
18:55:14 <dolphm> (5 min)
18:55:48 <dolphm> atiwari: since we don't have much time left, can you put together an example illustrating your concern and reply to one of henry's email on openstack-dev with it?
18:56:00 <atiwari> sure
18:56:08 <atiwari> I will do
18:56:17 <gyee> dolphm, henrynash, are we going with this? { "inherited to": ["domains", "projects"] }
18:56:45 <dolphm> inherits_to_projects = boolean
18:57:00 <gyee> k, I am getting conflict answer then
18:57:18 <dolphm> did i miss something?
18:57:27 <gyee> thought we are going with this { "inherited to": ["domains", "projects"] }
18:57:32 <gyee> I am cool with that
18:58:01 <topol> dolphm, please declare which way we are going. im getting confused
18:58:11 <dolphm> gyee: that's completely identical in functionality and extensibility to inherits_to_domains + inherits_to_projects
18:58:19 <topol> (boolean or enumeration)
18:58:35 <gyee> +1 on enum, -1 on multiple booleans
18:58:49 <henrynash> dolphm, gyee: yes, I see them as the same……
18:58:52 <dolphm> both of these are boolean-based approaches, it's just a matter of style... what we've decided is to *not* do full enumeration ('global', 'domain-global', 'project-local', etc)
18:58:58 <dolphm> i can't even remember the full enumeration
18:59:02 <topol> I can live either way
18:59:13 <henrynash> dolphm: exactly
18:59:22 <dolphm> yay
18:59:24 <dolphm> #endmeeting