Activity log for bug #942979

Date Who What changed Old value New value Message
2012-02-29 00:06:23 Joseph Heck bug added bug
2012-02-29 00:06:40 Joseph Heck devstack: status New Confirmed
2012-02-29 04:05:52 Jay Pipes description within keystone_data.sh: * devstack should create a tenant named "admin" * and keystone users for each service enabled in : ['nova', 'glance', 'horizon', 'quantum', 'swift'] * the script should also assign the role "admin:service" or "super" for each of those users against the tenant "admin" from associated thread on http://etherpad.openstack.org/keystone-admin-config: devstack should create tenant named "service", and users named "nova", "glance", "quantum", ... (or just a couple and describe that you could create an arbitrary number of users per service deployments) (termie) sure, "service" or "admin" (jesse) I'd like to have a name we recommend to deployers/operators to use - and service seems better?(jay) service is good. admins are people... services are, well, services. (termie) sure, i can get behind that -thrust- (jesse) then should we use a role "service" or "admin:service" or ? (jay) For the service role, I think the role should just be "super" or something like that, meaning no restrictions on use. Different from admin in that I view the term "admin" as a role for users, not services. (termie) well, right now there is only one admin role, so we are going to use that (jesse) for today ADMIN, for essex should we have a bug to use a different name (thinking of documentation) (termie) i feel like it is a relatively "new" feature to provide the granular access to things since to now we've only done admin, we could do it but it will require a lot of testing to get correct since it is adding additional permissions that weren't checked before (jesse) :( we should NOT change it if it adds anything more than a small risk..(jay) agreed, certainly for Essex. (termie) once i drop policy.py in this mofo i think we can at least experiment with it and if we feel really good about it we could make teh decision (jesse) eta for drop of policy - e4? (tonight) (termie) yes, at that point we can experiment with things, but the initial implementation will be no change to current policy (you are an admin or you are a public user) within keystone_data.sh: * devstack should create a tenant named "service"  * and keystone users for each service enabled in : ['nova', 'glance', 'horizon', 'quantum', 'swift']  * the script should also assign the role "admin" for each of those users against the tenant "service" from associated thread on http://etherpad.openstack.org/keystone-admin-config: devstack should create tenant named "service", and users named "nova", "glance", "quantum", ... (or just a couple and describe that you could create an arbitrary number of users per service deployments) (termie) sure, "service" or "admin" (jesse) I'd like to have a name we recommend to deployers/operators to use - and service seems better?(jay) service is good. admins are people... services are, well, services. (termie) sure, i can get behind that -thrust- (jesse) then should we use a role "service" or "admin:service" or ? (jay) For the service role, I think the role should just be "super" or something like that, meaning no restrictions on use. Different from admin in that I view the term "admin" as a role for users, not services. (termie) well, right now there is only one admin role, so we are going to use that (jesse) for today ADMIN, for essex should we have a bug to use a different name (thinking of documentation) (termie) i feel like it is a relatively "new" feature to provide the granular access to things since to now we've only done admin, we could do it but it will require a lot of testing to get correct since it is adding additional permissions that weren't checked before (jesse) :( we should NOT change it if it adds anything more than a small risk..(jay) agreed, certainly for Essex. (termie) once i drop policy.py in this mofo i think we can at least experiment with it and if we feel really good about it we could make teh decision (jesse) eta for drop of policy - e4? (tonight) (termie) yes, at that point we can experiment with things, but the initial implementation will be no change to current policy (you are an admin or you are a public user)
2012-03-01 14:51:03 Dean Troyer devstack: assignee Dean Troyer (dtroyer)
2012-03-01 17:11:18 Joseph Heck devstack: status Confirmed Fix Committed
2012-03-01 17:28:55 Joseph Heck devstack: status Fix Committed In Progress
2012-03-01 17:28:59 Joseph Heck devstack: assignee Dean Troyer (dtroyer) Joseph Heck (heckj)
2012-03-01 20:29:41 Joseph Heck devstack: status In Progress Fix Committed
2012-03-13 17:06:33 Dean Troyer devstack: status Fix Committed Fix Released