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