Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: In Current UI, we can't grant access to a single instance of a deployment. Also we can't revoke instance permissions to the user who launched it. Expected results: good to have Permission tab for instances. Additional info: rpm -qa | grep aeolus aeolus-configure-2.5.0-18.el6.noarch aeolus-conductor-daemons-0.8.0-43.el6.noarch aeolus-conductor-0.8.0-43.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-all-0.8.0-43.el6.noarch aeolus-conductor-doc-0.8.0-43.el6.noarch rubygem-aeolus-cli-0.3.0-14.el6.noarch
The impact of this is limited to the case of revoking permissions on the "owner" -- the user who launched it. We can revoke permissions for the user on the pool, and the deployment, but the user retains "instance owner" permissions on each instance. With no UI for per-instance permissions, there will never be any other users with direct per-instance permissions, so the only case this impacts us is a case where we want to revoke a user's access to instances he launched without disabling the user. i.e. if we're already disabling the user (left the organization, etc) it's a non-issue -- the issue is when we want to revoke permissions on instances that the user owns (and launched) without revoking access site-wide, since there's no UI to do this on right now. To add a permissions panel to the instance details screen is a pretty trivial fix (it's all modularized -- it took about 15 minutes of coding to add this to provider accounts recently. A slightly more involved solution, depending on business requirements around instances (vs. deployments/applications) would be to dump instance permissions entirely and key everything off the deployment/application. In this case we would be unable to grant permissions to one instance in a multi-instance deployment/application, so this solution would only be desirable if there will never be a use case for granting permission to only some of the instances in an application, especially since it's actually more dev effort to do this than to add a proper permissions panel, consistent with existing 'grant permissions' UI.