18:03:14 <dolphm> #startmeeting keystone 18:03:14 <openstack> Meeting started Tue Nov 19 18:03:14 2013 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:17 <openstack> The meeting name has been set to 'keystone' 18:03:24 <ayoung> all of our chatter will be at the end of their logs 18:03:29 <morganfainberg> LOL 18:03:33 <ayoung> dolphm, will be #2 in most lines spoken 18:03:38 <dolphm> primeministerp: just ended your meeting :) 18:03:59 <dolphm> anywho 18:04:03 <topol> dolphm cleaning up after others... 18:04:22 <dolphm> i'm going to ignore the agenda order a bit and leave bigger topics for the end... 18:04:25 <dolphm> so first up-- 18:04:36 <dolphm> #topic Deprecation of keystone.middleware.auth_token 18:04:43 <dolphm> morganfainberg: o/ 18:04:48 <bknudson> I thought it was deprecated. 18:04:52 <morganfainberg> i see the markings in the etherpad now 18:04:53 <dolphm> #link https://review.openstack.org/#/c/56143/ 18:04:55 <dolphm> bknudson: it's deprecated 18:04:58 <joesavak> \o 18:05:04 <morganfainberg> i'll unblock the removal review and we're good 18:05:09 <dolphm> but we're not using the new deprecated() call on import 18:05:12 <morganfainberg> i just wasn't 100% sure. 18:05:25 <bknudson> I think it's time to remove it. 18:05:26 <dolphm> and i don't think it can be completely removed until the end of icehouse, given the summit outcome? 18:05:34 <gyee> the time has come 18:05:39 <dolphm> was it deprecated during grizzly dev? 18:05:52 <dolphm> if so, then rm it 18:06:01 <gyee> +1 18:06:02 <morganfainberg> it was moved ot keystoneclient in grizzly 18:06:07 <dolphm> oh, then done 18:06:09 <dolphm> kill it! 18:06:11 <bknudson> would be nice to have a blueprint for this one. 18:06:15 <dolphm> #topic Update keystoneclient requirements failed in grenade 18:06:16 <bknudson> or but 18:06:20 <jamielennox> +1 18:06:24 <dolphm> bknudson: interesting idea 18:06:24 <ayoung> dolphm, if people are tracking master and have not updated that particualr one, this will be a wakeup call, but an easy one for them to adjust to 18:06:27 <bknudson> just so we advertise that it's removed. 18:06:53 <dolphm> #link https://bugs.launchpad.net/grenade/+bug/1252057 18:06:55 <uvirtbot> Launchpad bug 1252057 in grenade "keystoneclient requirements update fails grenade" [Undecided,New] 18:06:58 <dolphm> #link https://review.openstack.org/#/c/56490/ 18:06:59 <topol> its like 1 file in a crisis 18:07:00 <ayoung> bknudson, how a bout a generic deprecation blueprint? 18:07:24 <bknudson> ayoung: I like the general deprecation blueprint. 18:07:58 <stevemar-droid> Ayoung, That would be good 18:07:59 <ayoung> #action bknudson to file blueprint as catch-all for deprecations 18:08:08 <topol> question on deprecation. If I wanted to take a todo to deprecate stats do all I need to do is add the deprecated decorator evrywhere or do I need new test cases too? 18:08:13 * ayoung knows how to delegate! 18:08:27 <dolphm> ayoung: ++ 18:08:39 <ayoung> topol, oooh 18:08:45 <dolphm> topol: dstanek: thoughts on testing for deprecations? 18:08:50 <ayoung> topol, what if the tests failed on any deprecation warnings? 18:09:07 <topol> just asking, not recommending 18:09:13 <ayoung> topol, too late 18:09:22 <dstanek> i don't know that testing that a method is being deprecated is all that valuable 18:09:23 <ayoung> #action topol to make tests fail on deprecation warnings 18:09:29 <ayoung> :) 18:09:34 <dolphm> ayoung: we can move in that direction on a more granular basis (fatally error on items that have been deprecated for a release or two) 18:09:42 <morganfainberg> you can't make all test always fail on deprecation warnings. 18:09:53 <morganfainberg> you'd need to specifiy the release older-than to make it fail. 18:09:55 <ayoung> morganfainberg, sure you can 18:09:59 <dolphm> ayoung: no, you can't 18:10:04 <ayoung> you can't deprecate without providing an alternative 18:10:10 <ayoung> ah...cux of testing the told code, right 18:10:14 <jamielennox> the only reason i can see that being useful is if we want to maintain some sort of list of what is deprecated in the code and have a test to make sure they really are 18:10:15 <morganfainberg> yep 18:10:21 <dstanek> ayoung: you still keep the tests the exercise the old code 18:10:23 <jamielennox> otherwise i don't think i'd bother 18:10:32 <dolphm> dstanek: ++ 18:10:55 <morganfainberg> i want to work with dkranz and leverage the same mechanism as the exception tracking in gate to do a similar thing for tracking deprecated methods/functions 18:11:03 <gyee> its deprecated people, moving on 18:11:12 <bknudson> your tests exercising the old code can check that a deprecation message was output 18:11:14 <topol> so net is we can just start shoving deprecated on the things you want to deprecate? Should we split those up? 18:11:56 <bknudson> topol: split what up? 18:12:05 <morganfainberg> topol, ther eis a review for V2 controllers being deprecated, that is basically the approach. 18:12:11 <ayoung> topol, so, while you don't need new tests for the old methods, you do need new methods, and @deprecated tells what to use in palce of the old method 18:12:18 <topol> at the summit wasnt there a huge list of agreed things to deprecate? 18:12:25 <morganfainberg> #link https://review.openstack.org/#/c/50491/ 18:12:29 <dolphm> topol: https://etherpad.openstack.org/p/icehouse-keystone-internal-apis 18:12:39 <ayoung> so one way or anothter you are going to need a new test, either to continue testing the old code, or to check the new 18:13:01 <morganfainberg> ayoung, while it's deprecated you need to continue testing the old code and check the new 18:13:12 <morganfainberg> until it's removed that is. 18:13:14 <dolphm> i think we've covered deprecation pretty well for now :) let's move on to bknudson's grenade failure... 18:13:14 <morganfainberg> then the old test can go away 18:13:19 <ayoung> morganfainberg, we are in violent agreement 18:13:27 <dolphm> ayoung: ++ 18:13:43 <ayoung> problem with grenade failures is then you need to call in EOD 18:13:48 <dolphm> bknudson: care to explain/advertise the issue with grenade? 18:13:56 <bknudson> I added this topic because updating the requirements was a bit of a challenge recently 18:14:04 <bknudson> and still doesn't work... because of this grenade issue. 18:14:17 <bknudson> well, it fails in grenade... not sure if grenade is the problem. 18:14:29 <morganfainberg> bknudson, granade for master hasn't been bumped to stable/havana 18:14:35 <morganfainberg> which is likely the issue here 18:14:44 <bknudson> ok, so maybe this is a non-issue. 18:14:57 <bknudson> wasn't sure if opening a bug to grenade was the correct thing to do. 18:15:05 <bknudson> it's just failing and I don't know what the problem is. 18:15:07 <jamielennox> what is the collision with? having the requirements unversioned in keystoneclient is wrong but should make it easier in this case 18:15:11 <dolphm> dtroyer: ping ^ 18:15:11 <ayoung> bknudson, looks like glance needs a patch 18:15:12 <morganfainberg> i saw something in #openstack-infra about grenade not being bumped yet. also it's impacting nova's collapse migrations work 18:15:14 <bknudson> it complains about a mismatch of requirements. 18:15:25 <ayoung> why did they lock to that version of iso8601 18:15:29 <morganfainberg> error: Installed distribution iso8601 0.1.4 conflicts with requirement iso8601>=0.1.8 18:16:00 <dolphm> ayoung: there should be a bug referenced by the commit to pin in openstack/requirements 18:16:01 <jamielennox> but who requested 0.1.4 because this seems like there bug 18:16:03 <morganfainberg> iso8601 has (as i recall)... a source of random bugs. 18:16:05 <bknudson> is it the "old" (stable/havana) that needs the update? 18:16:10 <dolphm> ayoung: and a bug to unpin 18:16:15 <ayoung> dolphm, looking now 18:16:48 <morganfainberg> havana https://github.com/openstack/requirements/blob/stable/havana/global-requirements.txt#L23 18:16:54 <morganfainberg> uses 0.1.8 18:17:12 <morganfainberg> at least it should be according to global reqs 18:17:23 <ayoung> https://bugs.launchpad.net/glance/+bug/961590 18:17:25 <uvirtbot> Launchpad bug 961590 in glance "pip glance-2012.1~rc1 missing dependency iso8601" [Low,Fix released] 18:18:25 <jamielennox> that's from a whie ago 18:18:37 <ayoung> 8160ae293383ec600c05fd2e4b38164bca7704c4 18:18:54 <ayoung> Fixes bug: 1242501 18:18:57 <dolphm> https://github.com/openstack/requirements/commit/31c5f35b369ae531d09280a584cf3d80e9ae1eb7 18:19:09 <ayoung> iso8601>=0.1.7 "parse_date()" could successfully handle date string 18:19:09 <ayoung> which only have date part like YYYY-MM-DD, it caused two Glance test 18:19:09 <ayoung> cases failure. 18:19:22 <ayoung> guessing there is a "not" missing in that commit message 18:19:28 <dolphm> now i remember this conversation on list -- i was in favor of bumping to 0.1.8 :P 18:19:43 <bknudson> I think it was 0.1.7 had a bug that it didn't work anymore 18:19:54 <morganfainberg> bknudson, that is my understanding 18:20:04 <morganfainberg> s/is/was 18:20:35 <ayoung> ah, wait...is the lower version locked in Nova? 18:20:42 <dstanek> so is this just an issue of another project having conflicting requirements? 18:20:57 <bknudson> this is a tricky kind of problem because it involves so many different parts... grenade/keystoneclient/glance/stable/master... 18:21:07 <jamielennox> it seems like, so this is the bug of whoever locks to 0.1.4 18:21:11 <ayoung> bknudson, nah, we need them all to be in sync on dates 18:21:28 <morganfainberg> ayoung, nope nova is >=0.1.4 18:21:35 <morganfainberg> so, 0.8.1 should be acceptable 18:22:10 <bknudson> there's no requirements.txt in glance stable/grizzly? http://git.openstack.org/cgit/openstack/glance/tree/?h=stable/grizzly 18:22:22 <morganfainberg> bknudson, tools/pip-requires ? 18:22:53 <bknudson> morganfainberg: thanks, it's iso8601<=0.1.4 in there. 18:22:57 <morganfainberg> bknudson, yep. 18:23:05 <dolphm> bknudson: in where? 18:23:12 <morganfainberg> #link http://git.openstack.org/cgit/openstack/glance/tree/tools/pip-requires?h=stable/grizzly#n19 18:23:34 <dolphm> why are we worried about grizzly here? 18:23:38 <ayoung> dolphm, grenade 18:23:40 <dolphm> grizzly -> master migration? 18:23:47 <bknudson> so maybe it's just a matter of grenade needs to use havana and not master. 18:23:53 <dolphm> bknudson: sounds right 18:23:56 <morganfainberg> once grenade bumps to stable/havana my guess is this will go away 18:24:01 <ayoung> upgrade downgrade, guessing they are using the starting point being the stable branch? 18:24:22 <bknudson> I'll update the bug. 18:24:27 <dolphm> bknudson: there's not a bug to move to stable/havana https://bugs.launchpad.net/grenade/+bugs 18:25:07 <bknudson> morganfainberg: how did you know about the grenade issue? 18:25:12 <dolphm> bknudson: maybe revise the title of your bug with the underlying issue? 18:25:13 <bknudson> that it wasn't using stable/havana? 18:25:23 <dolphm> bknudson: discussed on list, i think 18:25:42 <morganfainberg> bknudson, i lurk in in #openstack-infra and i think something on the ML 18:26:38 <bknudson> ok, that answers my questions about this. 18:26:52 <bknudson> thanks! 18:26:57 <morganfainberg> https://review.openstack.org/#/c/57066/ 18:26:57 <dolphm> ( bknudson- i think i can help you after the meeting on "assignments-doesn't-check-identity" -- mind if i skip that for the meeting, or save it for open discussion? ) 18:27:12 <bknudson> we can skip that one. 18:27:24 <ayoung> Reminder that I1 is going to sneak up on us. 18:27:24 <dolphm> woo! i think this next one is going to eat the next 30 minutes 18:27:26 <bknudson> also, don't see henrynash. 18:27:30 <dolphm> ayoung: ++ two weeks! 18:27:46 <dolphm> #topic Tenantless role assignments 18:27:50 <shardy> o/ 18:27:52 <gyee> dolphm, is the detail schedule out yet? 18:27:53 <morganfainberg> dolphm, oooooooh 18:27:57 <dolphm> so first point -- not global role assignments 18:28:09 <ayoung> Roles are always scoped 18:28:11 <dolphm> gyee: yes, pay more attention to things https://wiki.openstack.org/wiki/Icehouse_Release_Schedule 18:28:16 <ayoung> either to a Domain or a Project 18:28:23 <dolphm> ayoung: so this is a new scope 18:28:40 <dolphm> and it's explicitly scoped to a a lack of context 18:28:44 <ayoung> dolphm, "service scoped" will make atiwari happy 18:28:47 <dolphm> not *any* context 18:28:48 <bknudson> turkey / football / reviews. 18:28:54 <gyee> k, looks like it just got updated 18:28:55 <atiwari> I think all the identity roles does not require a tenant 18:29:07 <dstanek> what does the scope apply to if it's not global? 18:29:29 <dolphm> looking at a bunch of API's in openstack, they all fall into one of two categories... 18:29:41 <ayoung> shardy, this is your use case. Care to explain, or to link to an explanation 18:29:43 <dolphm> 1) it's an inheritenly multi-tenant operation (create compute) 18:29:46 <bknudson> one oddity is if you have admin role on any project then you have admin auth all over keystone 18:29:57 <dolphm> 2) it's an inherently tenant-less operation (create domain) 18:30:09 <dolphm> or service catalog management 18:30:09 <shardy> ayoung: https://etherpad.openstack.org/p/heat-management-api 18:30:21 <dolphm> or some/all of heat's proposed administrative api 18:30:22 <morganfainberg> so, to do project-management admin you'd still need to rescope to that project? 18:30:30 <shardy> ayoung: tl;dr, folks want a way to list all stacks owned by heat, not scoped to a tenant 18:30:44 <dolphm> morganfainberg: i'd like that to be the result, yes 18:30:49 <ayoung> "stacks?" 18:30:51 <morganfainberg> dolphm, i like the idea 18:31:03 <morganfainberg> dolphm, i really dislike the "admin here admin everywhere" setup 18:31:08 <shardy> ayoung: stacks are what users of heat create 18:31:21 <dolphm> so, the only way to consume a tenant-less assignment (that i'm in favor of) would be to generate an unscoped token -- which becomes an explicit operation to gain authorization for tenant-less operations 18:31:39 <dolphm> morganfainberg: i think we all do! 18:31:42 <shardy> ayoung: the point is, service deployers want a way of getting global information, like number of resources in a certain state, ie globally 18:31:43 <dolphm> this would be a way to fix "admin"ness 18:31:52 <bknudson> you can assign roles for unscoped tokens? 18:31:58 <dolphm> bknudson: that's the idea here 18:32:05 <morganfainberg> bknudson, i don't think so at the moment. that is the proposal 18:32:05 <atiwari> or scope a role to service and for tenant less that wd be scoped to Keystone 18:32:08 <dolphm> morganfainberg: ++ 18:32:45 <ayoung> dolphm, so to date we have domains, and we have projects. Domains own projects. We have the Default domain, which has been suggested as the nominee for the "admin" domain. But, would having an explicit admin domain solve this problem? 18:33:03 <bknudson> a token scoped to a service could have roles ? 18:33:05 <ayoung> "admin" would mean "admin role on the default domain" or "admin domain" 18:33:15 <bknudson> like heat service has admin role 18:33:19 <ayoung> atiwari, Keystone is a service 18:33:23 <dolphm> ayoung: abusing the "default" domain in that way is insanely terrible 18:33:47 <dolphm> ayoung: so yes, this would be a more explicit approach that avoids that hack/abuse 18:33:53 <morganfainberg> ayoung, if we made the "admin domain" implicit, as in a code construct not a DB construct, i could see that as viable. but i think you get more flexabvility with unscoped roles. 18:34:06 <ayoung> dolphm, "default" probablty, but having an explict admin domain as a way to collect up the service resources is a valid use of the current abstraction 18:34:32 <ayoung> roles are always scoped, we just need to determine to what are they scoped in this case. 18:34:37 <ayoung> Either an existing abstraction or a new one 18:34:47 <ayoung> atiwari has been pushing for service scoped roles for a while 18:34:54 <shardy> ayoung: would that require all services to know about domains though? 18:34:59 <atiwari> ayoung, yes but it does not have any roles 18:35:12 <morganfainberg> shardy, if done properly, perhaps not 18:35:15 <gyee> unscoped roles are essentially scoped to keystone service, as atiwari mentioned 18:35:23 <atiwari> if we create keystone specific role and make those roles assign to domain only 18:35:26 <gyee> just like unscoped tokens 18:35:29 <henrynash> (henry-nash) joint (sorry to be late) 18:35:29 <atiwari> Heat issue can be addressed 18:35:31 <ayoung> gyee, so scope them to a service, and make keystone that service 18:35:34 <henrynash> joined, even 18:35:35 <dolphm> i don't think this proposal is new -- this is the valid use case for "global roles", but those deeply ingrained in the "multitenant architecture" train of thought find "global authorization" to be an offensive over step 18:35:40 <ayoung> but...still think services should be owned by a domain 18:35:43 <morganfainberg> henrynash, welcome. 18:35:56 <dolphm> hopefully i'm just wording that use case differently and narrowing the scope of application as much as possible 18:35:56 <ayoung> "admin domain" which, if not set, would be the "default domain" 18:36:00 <dstanek> i see how this helps the services act in a global way, but how does it help the "admin"ness issue? 18:36:33 <morganfainberg> dstanek, you wouldn't have admin powers in this context unles you were using a service scoped role vs. a domain/project role. project/domain admin could only act on project/domain 18:36:43 <bknudson> we'll need something to set in the policy.json. 18:36:48 <morganfainberg> dstanek, that would be part of this change in scope capability 18:37:20 <dolphm> i'd also like to kill the terminology of "unscoped tokens" in favor of "tenantless tokens" along the way -- there is and has always been a scope to "unscoped" tokens 18:37:26 <dolphm> "tenantless" makes that a bit more clear 18:37:35 <morganfainberg> projectless? domainless? 18:37:35 <topol> so how does this make things simple for shardy's use case? 18:37:35 <ayoung> projects are generic containers. Domains are containers of projects. Services, and even "role definitions" are resources, and should be put into a namespace. Samething as we insit on with out python code 18:37:40 <atiwari> ayoung, service owned by domain on a project 18:37:52 <dolphm> morganfainberg: projectless implies domain-scoped, and vice versa to me -- but i'm open to alternative suggestions 18:38:01 <dolphm> morganfainberg: thinking in terms of traditional tenancy led me to "tenantless" 18:38:06 <morganfainberg> dolphm, maybe unscoped = service scoped. always scoped tokens now. 18:38:12 <atiwari> by keystone is little different it can not be owned by a domain 18:38:22 <dolphm> morganfainberg: regardless of what your deployment considers to be a "tenant" (per domain or per project) 18:38:30 <ayoung> morganfainberg, and implicitly, on keystone unscoped == scoped to keystone 18:38:32 <gyee> unscoped = keystone-scoped 18:38:35 <morganfainberg> ayoung, yes. 18:38:45 <morganfainberg> ayoung, +++ exactly 18:39:05 <ayoung> so, just be clear, theser are "service scoped role assignments" but atiwari 's proposal goes further 18:39:07 <shardy> topol: If a request context doesnt' contain a request context, and the user has a special admin-ish role, we allow them to get data not filtered by tenant 18:39:10 <ayoung> so... 18:39:24 <shardy> topol: sorry doesn't contain a project in the context 18:39:32 <ayoung> role definitions should be scoped to other roles, and should be managed resources 18:39:34 <atiwari> ayoung, lets not messup with role assignment 18:39:34 <ayoung> ie 18:39:42 <gyee> ayoung, atiwari's proposal solved *service lifecycle management* use case 18:39:51 <ayoung> atiwari, we need to address it 18:39:51 <bknudson> does the service (via auth_token_middleware) need to know that this is a service-scoped token? 18:40:00 <topol> what is the special admin-ish role? 18:40:06 <atiwari> but let role derive the service 18:40:16 <ayoung> atiwari, that doesn't work 18:40:23 <atiwari> why? 18:40:24 <dolphm> bknudson: yes 18:40:31 <topol> shardy sounds like the mob is moving to doing this with a service scoped token? 18:40:32 <shardy> topol: some role you create and put in the heat config file 18:40:41 <ayoung> that implies that a role is always per service, and that breaks all the existing roles 18:40:43 <dolphm> bknudson: it wouldn't provide a X-PROJECT-* or X-DOMAIN-* but there would still be X-ROLES 18:40:44 <shardy> topol: that would also work 18:40:49 <ayoung> atiwari, we hashed this out... 18:40:56 <ayoung> roles are 1st class objects already 18:41:12 <morganfainberg> dolphm, ah for external services to consume service scoped 18:41:24 <dolphm> i.e. heat! 18:41:25 <ayoung> we make it such that some container (I really don't care which) owns a role definition, and we provide for nesting of role definitions 18:41:26 <gyee> ayoung, atiwari's proposal is backward-compatible 18:41:40 <ayoung> gyee, not as it was origianll written it wasnt 18:41:42 <morganfainberg> ayoung, roles all the way down. 18:41:48 <ayoung> morganfainberg, pretty muich 18:42:00 <ayoung> bascially, role-defs need a namespace 18:42:00 <gyee> existing roles will be migrated to keystone namespace 18:42:09 <ayoung> but we don't need to inject yet another abstraction 18:42:14 <ayoung> gyee, nope 18:42:15 <atiwari> ayoung, but it can not be managed by service deployer 18:42:17 <ayoung> that does not work 18:42:17 <dolphm> gyee: then you break everyone 18:42:30 <ayoung> thos roles are "project" focused, not "keystone" focused" 18:42:32 <morganfainberg> ayoung, i'm fine with that approach. i don't want another domain / project grouping mechanism. roles can contain roles and it's logical. 18:42:47 <gyee> dolphm, no, this is the way we migrated the existing resource to the *default* domain when we introduced domain 18:42:48 <ayoung> morganfainberg, that is what I am proposing 18:43:14 <morganfainberg> ayoung, more vehement agreement! 18:43:44 <ayoung> namespaceing roles to services is only one view of them, and it only makes sense in the use cases atiwari is looking to implement, but I would not say that his issue is a general problem in Openstack. 18:43:48 <topol> so ayoung, net it out. how do we do this without breaking everyhting? 18:43:54 <henrynash> ayoung: but is that solving the problem that antiwar is trying to solve…which is you want a new service (that is not relate to an existing one) to be able to create roles that it and only it will consume (vis its policy file)? 18:44:03 <dolphm> ayoung: then where is it a problem? 18:44:18 <morganfainberg> henrynash, if that service has a role grouping, sure? 18:44:40 <ayoung> dolphm, for openstack right now, a role is implicitly multi-service 18:44:41 <gyee> ayoung, atiwari is solving service lifecycle management use case 18:44:46 <gyee> for the second time :) 18:45:01 <morganfainberg> henrynash provided policy enforcement can provide that i think it would work. 18:45:04 <ayoung> _member_ is used implicitly for all sercvices wherea user needs access to aa project's resources 18:45:05 <dolphm> ayoung: i'd say that pretty explicit, considering nothing about authorization is bound to a particular service 18:45:11 <atiwari> yes and that seems to me a general issue 18:45:13 <atiwari> :) 18:45:19 <ayoung> we are not going to say " noav_memeber, glance_memeber...etc 18:45:35 <dolphm> ayoung: _member_ is an explicit representation of v2 default tenancy 18:45:37 <ayoung> Keystone cares nothing about this 18:46:02 <ayoung> dolphm, and we can break things up more granularly, but thus far, we have ben careful not to impose on the implementoars view of things 18:46:28 <ayoung> but _member_ is scoped to project, not to service 18:46:30 <henrynash> is the "role grouping" proposal (as opposed to the role service model) documented anywhere? 18:46:43 <ayoung> henrynash, I'm keeping it in the same BP 18:46:52 <henrynash> ayoung: ok 18:46:58 <ayoung> no reason to have two competing ones, as I think this solves atiwari 's use cases 18:47:03 <ayoung> it is just the more general solution 18:47:29 <ayoung> so...we have two unmanaged resources right now: services and roles...well, more than that, but lets start there 18:47:48 <ayoung> who can add a new service? Who can add a new role? Keystone admin 18:47:50 <dolphm> ayoung: right, because _member_ is a representation of default tenancy -- not anything service-specific 18:47:53 <atiwari> ayoung, can you add your idea in etherpad ? 18:48:01 <ayoung> but, atiwari has the use case where many more services are going to be registered 18:48:18 <gyee> yes, AaaS for example 18:48:23 <ayoung> and for each service, it needs to be able to define its own roles 18:48:24 <ayoung> NP 18:48:31 <atiwari> yes, may be non Openstack service 18:48:33 <ayoung> make a namespace for each service 18:48:45 <ayoung> but...don't force that namespace to be the service 18:48:46 <morganfainberg> ayoung, the way i see it is keystone scoped admin can add services. adding a role to an service would be in the services namspace? 18:49:03 <ayoung> morganfainberg, so keep the namespace and service as separate but parallel 18:49:12 <ayoung> services get roles, but so do projects etc 18:49:14 <gyee> morganfainberg, ++ 18:49:15 <morganfainberg> ayoung, that is what is forming in my head. 18:49:22 <dolphm> ayoung: services already define their own roles by defining their own authorization policy which converts user attributes into available capabilities 18:49:48 <ayoung> dolphm, yeah, bascially, but they don't then go and register those roels in keystone yet, that is what is missing 18:50:11 <ayoung> dolphm, I'm OK with the roles being namespaced, but even two different glance servers might have different role sets 18:50:11 <shardy> ayoung: surely that's just an install-time thing in most cases? 18:50:15 <morganfainberg> ayoung, i think new services need to be added by a keystone-service admin scoped role (yes there is a bootstrapping issue) 18:50:40 <ayoung> shardy, absolutely install time. 18:50:48 <atiwari> morganfainberg, that is a dependency issue 18:51:02 <gyee> morganfainberg, we can create the bootstrap service-admin role at service creation 18:51:05 <atiwari> keystone should be out of hook 18:51:05 <ayoung> so lets not lock ourselves into saying that the namespace exactly equals the service 18:51:10 <ayoung> cuz that is very rigid 18:51:26 <gyee> same way we do default project, with the _member_ assignment 18:51:31 <dolphm> ayoung: "but they don't then go and register those roels in keystone" which is one reason why it was a mistake to make roles first class objects 18:51:39 <ayoung> Create a new service, get a role that has the same name as that service by default? I'm fine with that 18:51:49 <ayoung> then that role serves as the namespace for all roles for that service 18:52:08 <ayoung> dolphm, nah, in reality people need that 18:52:13 <ayoung> you have to have an enumeration 18:52:27 <ayoung> the implementation was a good first step 18:52:47 <ayoung> we just need a way to namespace roles, and to delegate the administration of the roles 18:52:48 <dolphm> ayoung: you can still enumerate strings 18:52:54 <dolphm> ayoung: which is all anyone cares about with roles 18:53:07 <dolphm> ayoung: the ID is useless, even auth_token reflects that 18:53:08 <ayoung> dolphm, but you don't want to enumerate all strings on all role assignements. 18:53:23 <atiwari> roles should be registered in keystone for assignments 18:53:30 <morganfainberg> ayoung, dolphm, are we arguing normalization vs non-normalized here? 18:53:31 <dolphm> ayoung: ? i'm saying a role is nothing more than a string 18:53:37 <ayoung> dolphm, I know you feeel buyers remorse about creating the role enumeration abstraction, but I think it is a needed documentation 18:53:39 <dolphm> ayoung: there's no relevant metadata to a role entity 18:54:14 <ayoung> dolphm, so the use case atiwari has is interesting, in that he wantss to be able to rename or even mve sets of roles 18:54:27 <ayoung> so...roles as names becomes more like the regions thing 18:54:50 <ayoung> the roel assignment will have an ID, but you can change the name and all of the assignemtnes get updated 18:54:57 <atiwari> dolphm, you are correct but there should be some management involved with role too and you can not do that until you name space it to service 18:55:01 <ayoung> say we create a role named glance 18:55:07 <dolphm> i would be totally cool if PUT /v3/users/{user_id}/projects/{project_id}/roles/{role_name} created a new role automatically if it didn't exist with id={role_name}, name={role_name} 18:55:07 <ayoung> and under that glance/id 18:55:26 <ayoung> then realize that glance/id should have been really under swift, and been called swift/moderator 18:55:47 <morganfainberg> ayoung, if we do that i would use something like <role>.<role> (e.g. glance.member) nomenclature. 18:55:55 <atiwari> #link https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition has the real issue we need to resolve 18:55:56 <ayoung> all people that have that role will be updated when you move the id /change the role definition 18:56:19 <ayoung> morganfainberg, either dots or slashes or slashdot 18:56:22 <dolphm> ayoung: that's not interesting at all, because services can already do that by changing their policy.json 18:56:23 <ayoung> ...---... 18:56:32 <morganfainberg> .././.././///.. 18:56:49 <ayoung> dolphm, no, they can only change what will be matched 18:56:55 <gyee> testing 18:57:01 <gyee> thought we are having keyboard issue 18:57:32 <morganfainberg> dolphm, i think the biggest win to have a structure is if you want to revoke a role completely. if it's just strings in metadata it's expensive to remove that role from all users in a service. 18:57:57 <ayoung> atiwari, so I am in strong favor of your requirement, I just don't want to make the mistake of locking it to the "service" abstraction for the namespace. Cool? 18:58:26 <henrynash> morganfainberg: although it won't be strings in metadata with the assignment table change….should be one SQL command 18:58:27 <dolphm> morganfainberg: eek, we didn't consider 'delete role' in https://etherpad.openstack.org/p/icehouse-token-revocation 18:58:33 <atiwari> ayoung, as I mentioned it is not locking 18:58:44 <morganfainberg> dolphm, yeah. 18:58:46 <atiwari> anyone service can have Admin roles 18:58:48 <ayoung> service scoped role should be a supported use case, but the abstraction is "role namespace" 18:58:49 <dolphm> at least, maybe not very well 18:58:58 <atiwari> no one can stop them 18:59:00 <morganfainberg> dolphm, oh i don't think we did. 18:59:07 <topol> um, kinda getting lost. So how do we solve shardys use case? 18:59:28 <ayoung> topol, the question for shardy 's case is "what is the implicit scope" 18:59:41 <ayoung> what scope does a "satack" live within? 18:59:43 <ayoung> stack 18:59:52 <dolphm> ayoung: there is no "implicit scope" in his use case 19:00:00 <henrynash> ayoung: so I could be persuaded if I understand the additional problems that level of generic abstraction gets us 19:00:03 <shardy> ayoung: All user requests are tenant scoped, but these management requests wouldn't be scoped to anything 19:00:04 <ayoung> dolphm, there is "always" implicit scope. 19:00:09 <ayoung> lets make it explicit 19:00:13 <gyee> lets call it what it is, global roles 19:00:17 <dolphm> ayoung: that's the idea of tenantless role assignments 19:00:28 <dolphm> gyee: it's not a global role at all - read the blueprint 19:00:37 <shardy> ayoung: or, it's scoped to the service, as it's a heat service adminstrator action 19:00:47 <ayoung> gyee, it is never "global" cuz the world is so big. I think it is "scoped to this openstack deployment" maybe, but then we are already ignoring prior art 19:00:54 <morganfainberg> shardy, that would be a good approach actually. 19:00:56 <dolphm> time's up! 19:01:01 <ayoung> whe I startedo n Keystone, admin was supposed to be scoped to the "admin" project 19:01:05 <ayoung> somehow that got lost 19:01:12 <dolphm> #endmeeting