Difference between revisions of "Manila/design/access groups"
(→How it works in different situations) |
(→How it works in different situations) |
||
Line 58: | Line 58: | ||
===== How it works in different situations ===== | ===== How it works in different situations ===== | ||
− | '''Ques 1. Lets say | + | '''Ques 1. Lets say a user requests allow-access-group for (share1, AG1)''' |
'''What if the share is already mapped to another access_group/access_rule.''' | '''What if the share is already mapped to another access_group/access_rule.''' | ||
− | Ans: Nothing, set of access_rules for AG1, will be applied on share using 'add_rule' | + | Ans: Nothing, set of access_rules for AG1, will be applied on share, using 'add_rule' |
field of 'update_access' helper function. | field of 'update_access' helper function. | ||
− | '''Ques 2. lets say | + | '''Ques 2. lets say 'share1' has an already applied access rule i.e ( user ,admin, rw).''' |
'''Now, 'AG1' contains (user, admin, ro). A request comes as 'allow_access_group(share1, AG1)'.''' | '''Now, 'AG1' contains (user, admin, ro). A request comes as 'allow_access_group(share1, AG1)'.''' | ||
− | ''' | + | '''share1 is asked to map with AG1, what should happen?''' |
'''What if the already applied rules are redundant to AG1's access rules.''' | '''What if the already applied rules are redundant to AG1's access rules.''' | ||
Line 73: | Line 73: | ||
Ans: Its same as case, if we apply two redundant rules, even without access-groups. We will get an exception, 'access rule for (user, admin) | Ans: Its same as case, if we apply two redundant rules, even without access-groups. We will get an exception, 'access rule for (user, admin) | ||
− | + | already exists' and we will proceed to examine, rest of the rules, in access_group. '''We need to deny this rule first "to change its level if required.''' | |
'''Ques 3. What if AG1 is made up of n rules, only one is redundant ?''' | '''Ques 3. What if AG1 is made up of n rules, only one is redundant ?''' | ||
− | Ans:If any one of the access_rule from this access_group, is already applied on share(individually) | + | Ans:If any one of the access_rule, from this access_group, is already applied on share(individually)... |
− | + | lets say due to 'allow-access' api. Then excluding that access_rule, rest of the rules, present in 'access_group' will be applied on share. | |
− | '''Ques 4. What if AG1 is made up of n rules, an error reported from backend for one of the rules?''' | + | '''Ques 4. What if AG1 is made up of 'n' rules, an error reported from backend for one of the rules?''' |
− | Ans: If there is an error reported from backend, then error will be registered in share_instances table. | + | Ans: If there is an error, reported from backend, then error will be registered in share_instances table. |
− | + | 'access_rules_status' will go in 'error' state and 'access_status_message' will contain the descriptive message. | |
'''Ques 5. What if access group is already mapped to other shares and this is a new mapping.''' | '''Ques 5. What if access group is already mapped to other shares and this is a new mapping.''' |
Revision as of 10:29, 1 April 2016
Contents
Applying Access Rules
Current approach
Today we use "manila allow-access" and "manila deny-access" cli command, to allow and deny "one" ip address/user/cert, the access, to a particular share. In situation, when we want a "share" to be accessible by
- a subnet OR
- a set of IP addresses together OR
- a set users together
we have to execute allow-access for each combination of (IP address, share) one by one!! That is, If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then it requires "n iterations for each of n shares", that's n^2 operations from user side. That's cumbersome hence access-groups were proposed
Requirement
Requirement is to have a mechanism, by which a set of "ip addresses" can be considered as "one entity" i.e. can be allowed the access to a share together. Henceforth, the "same set of ip addresses" 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_group" can be created by user. Each "access_group" contains a bunch of homogeneous "access_entries". Homogeneous here means entries of same access_type & access_level(in case access_type is "user")"). Each "access_entry" represents, either one "ip-address" or one "user-name". Bunch of access entries associated to an "access-group", can be "allowed or denied" access, to a share in one go.
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
- With new proposal, a set of access-rules can be applied together using "access-group". 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 api. That has to be understood and resolved.
- A parallel api interface, serving same purpose, but in different granularity, causes redundancy in database and information.
- Sending a bunch of rules together to backend, if any one rule throws an exception, status of whole access-group will be errored.
- If backend driver doesn't implement 'update_access' newer version yet, then 'access-rules' will be sent to driver one by one only.
Though 'access-group' feature will allow user, to request access, to set of ip addresses, in one go, still backend will work on access-rules individually.
Proposed Object Relationships:-
Important Actions
Sr No | Function | Command |
---|---|---|
1 | Create Access Group | manila access-group-create [--access-level <access_level>] <name> <description> <access_type> |
2 | Add Access Group Entries in Access group | manila access-group-entry-create <access_to> <access_group_id> |
3 | Allow Access Group to a share | manila access-group-allow <share> <access_group_id> |
4 | Deny Access Group to a share | manila access-group-deny <share> <access_group_id> |
Flow diagram
Allow Access Group
Deny Access Group
How it works in different situations
Ques 1. Lets say a user requests allow-access-group for (share1, AG1) What if the share is already mapped to another access_group/access_rule.
Ans: Nothing, set of access_rules for AG1, will be applied on share, using 'add_rule' field of 'update_access' helper function.
Ques 2. lets say 'share1' has an already applied access rule i.e ( user ,admin, rw). Now, 'AG1' contains (user, admin, ro). A request comes as 'allow_access_group(share1, AG1)'. share1 is asked to map with AG1, what should happen?
What if the already applied rules are redundant to AG1's access rules. Note:- its a redundant rule, not contradictory, as rules with 'same access_type and access_to' are considered redundant..
Ans: Its same as case, if we apply two redundant rules, even without access-groups. We will get an exception, 'access rule for (user, admin) already exists' and we will proceed to examine, rest of the rules, in access_group. We need to deny this rule first "to change its level if required.
Ques 3. What if AG1 is made up of n rules, only one is redundant ?
Ans:If any one of the access_rule, from this access_group, is already applied on share(individually)... lets say due to 'allow-access' api. Then excluding that access_rule, rest of the rules, present in 'access_group' will be applied on share.
Ques 4. What if AG1 is made up of 'n' rules, an error reported from backend for one of the rules?
Ans: If there is an error, reported from backend, then error will be registered in share_instances table. 'access_rules_status' will go in 'error' state and 'access_status_message' will contain the descriptive message.
Ques 5. What if access group is already mapped to other shares and this is a new mapping.
Ans: Simply, rules from the access-group will be applied on the requested share.
Ques 6. Two compatible access-groups mapping request got out of order before reaching backend driver.
Lets say two api requests for two access_groups where two access groups's rules are compatible as below: Two api requests come in this order chronologically, req1 then req2, AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None) req1 = allow_access_group(share1, AG1), req2 = allow_access_group(share1, AG2) Let’s say these request reach driver layer, out of order, driver receives req2 then req1. What will happen in such case?
Ans: req1 creates a access_group_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer. req2 also creates a access_group_mapping in db for (share1 -> AG2) and passes that “only set of rules in AG2" to driver layer. Driver layer gets req2 first, it will apply access_rules of req2 first and then access_rules from req1 will be applied on backend.
Ques 7. What happens if an exception is raised for one of the access-rules in access-group in api layer itself? Do we proceed for next rule or we come out ?
Ans: These are such exceptions which come like 1)if share status is not AVAILABLE >> we raise exception and come out 2)If share_access entry already exists for this share ? >> we raise exception but continue to consider next access_rule 3)if access_level value requested for is not a valid value >> we raise exception and come out 4)If share_instance is invalid one >> we raise exception and come out 5)if access_rules_status is not active >> we raise exception and come out
in all such cases we raise exception before rpc request is sent to driver layer. access_status_message" field in "share_instances" table - does not show error messages for above mentioned exceptions. Note:- in last two cases(4,5), though we come out, but 'share_access_group_mapping' and 'many share_access_map' entries would have been created!!!
Ques 8. What is purpose of access_rules_status and access_status_message field in share_instances table?
Ans: access_status_message field, registers the error message, from the driver layer. if we get an error message back from driver, it gets registered in 'access_status_message' in 'share_instances' table. 'access_status_message' field in 'share_instances' table - does not register error messages for above mentioned exceptions in Ques7.
Ques 9. Lets say an access-group that contains 4 access_rules, that is applied on a share1. now these 4 access_rules have got their entries created in share_access_map too. What is someone deleted/denies the access rule individually ? that is sequence is like 1) manila access-group-allow <share-id> <access-group-id> 2) manila access-deny <share> <id> 3) manila access-group-deny <share-id> <access-group-id> Now some rules of this access-group are denied individually .. when we go to 'deny-access-group' what will happen?
Ans: For each of 4 rules, if anyone is not present in the DB, we raise exception Not-Found and continue to next access_entry.
Ques 10. Lets say a share share1 is mapped to an access_group AG1. Now we delete one of access_rule of AG1 or we add an entry to mapped access_group AG1. What will happen?
Ans: any addition or deletion of access_entry to an access_group after being mapped, will trigger 'update_access' on the backend.