Difference between revisions of "Manila/design/access groups"
(Created page with "<gallery> Example.jpg|Caption1 Example.jpg|Caption2 </gallery> == Current design of access rules === Today we use "manila allow-access" and "manila deny-access" cli to allow a...") |
(→Current design of access rules =) |
||
| Line 3: | Line 3: | ||
Example.jpg|Caption2 | Example.jpg|Caption2 | ||
</gallery> | </gallery> | ||
| − | == Current | + | == Current approach for access rules to a share=== |
| − | 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 | + | 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 |
| − | a set of ip addresses together | + | to a subnet OR |
| + | a set of ip addresses together OR | ||
| + | a set users together | ||
| + | we have to allow each ip address separately one by one!! | ||
| + | If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then n number of ip addresses will require n iterations for each share | ||
| + | that's n^2 operations from user side. That's cumbersome hence access-groups were proposed. | ||
| − | === | + | === Requirement === |
| − | + | Requirement is to have a mechanism so that a set of ip addresses can be considered as one entity, can be allowed the access to a share together. | |
| − | There comes the idea of manila access-groups | + | Henceforth, the same set can be allowed access to any other share in one single request from user. There comes the idea of manila access-groups. |
=== Manila Access groups === | === Manila Access groups === | ||
| − | + | 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. | ||
| − | + | Access Group contains a set of "homogeneous access_entries". Each "access_entry" holds either one "ip-address" or one "user-name" at a time. | |
| − | + | Feature requirement is to provide a mechanism, to allow the access to a share for "a group of ip addresses/users", in one go, | |
| − | + | instead of allowing each ip-address/user one at a time. | |
=== Challenges === | === Challenges === | ||
| Line 24: | Line 30: | ||
Object Relationships:- | Object Relationships:- | ||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 06:51, 31 March 2016
- Example.jpg
Caption1
- Example.jpg
Caption2
Contents
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 together we have to allow each ip address separately one by one!! If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then n number of ip addresses will require n iterations for each share that's n^2 operations from user side. That's cumbersome hence access-groups were proposed.
Requirement
Requirement is to have a mechanism so that a set of ip addresses can be considered as one entity, can be allowed the access to a share together. Henceforth, the same set can be allowed access to any other share in one single request from user. There comes the idea of manila access-groups.
Manila Access groups
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.
Access Group contains a set of "homogeneous access_entries". Each "access_entry" holds either one "ip-address" or one "user-name" at a time. Feature requirement is to provide a mechanism, to allow the access to a share for "a group of ip addresses/users", in one go, instead of allowing each ip-address/user one at a time.
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:-
