Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
ACL implementation is a mechanism of permission management. Currently only one type of permission is available: full access for the owner, no access for other users or tenants.
Purpose of ACL: make different volume access permissions possible.
Why useful? 1) Granting different access permissions to volumes, which can establish a foundation for volume transfer, read-only volumes (more flexible, than implemented in havana), public volumes, etc. 2) The owner of the volume and the administrators always have the full access and can assign the permission to other users or group of users.
Some use cases 1) as a foundation for read-only volumes (with flexible configuration, currently only 2 options are available: R/O for everyone or R/W for everyone)
Owner or Admin would be able to grant R/O access for the another user (or for users in a user group, or for a tenant, or everyone).
2) as a foundation for public(i.e. cross-tenant visible) volumes (currently Volume is visible for all the users from the only tenant)
Owner or Admin, or someone with the sufficient access level would be able to make a volume visible for all the tenants just by setting some access permission for "everyone" project.
Proposal to discuss 1) Remaking havana's ACL design to embrace foundations for read only and public volumes 2) Changing a representation of permission levels (in order to easy an aggregation of some access permissions in case if User in some groups with different access permissions e.g.)
