Manila/design/access groups
- Example.jpg
Caption1
- Example.jpg
Caption2
Contents
Current design of access rules =
Today we use "manila allow-access" and "manila deny-access" cli to allow and ip address/user the access to a particular share. In case we want a share to be accessible to a subnet or a set of ip addresses together or a set users we have to allow each ip address one by one. If we want to allow 'n' ip addresses for each of 'n' shares, then n number of ip addresses will require another n iterations for each share that's n^2 commands from user.
Proposal
Proposal is to have a mechanism so that a set of ip addresses as one entity, can be allowed to access a share together and that set can be allowed access to any other share in one go. There comes the idea of manila access-groups
Manila Access groups
Access Groups is a object contains a set of homogeneous access_entries. Each access_entry holds one ip-address or one user-name. This feature is to provide a mechanism, to allow access to a group of ip addresses/users, in one go, instead of allowing each ip-address/user one at a time.
Proposal :-
A new object named "access_groups" will be created by user. Each "access_group" represents a bunch of "access_rules" of same "access_type & access_level". Bunch of access rules can be either a set of ip addresses or can be set of users, to be allowed or denied in a go.
Challenges
A set of rules applied in a bunch using access-groups. Earlier "allow-access/deny-access" api works on individual access rules. So it can interfere and allow/deny any access without any knowledge of access-group. That has to be taken care of.
A parallel interface to serve same purpose but in different granularity, causes redundancy in database and information.
Object Relationships:-
- Https://wiki.openstack.org/wiki/File:DB relationships.png
