OpenStack - User contributions [en]

Manila/design/access groups

2016-05-11T05:40:41Z

Nidhi Mittal Hada:

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== 2nd Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database as compared to 1st approach.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope', same as the share,
its associated with. So no further means to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???
I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share1' ,AG1)

* If share is deleted and if its last share which was associated with a access-group, the access-group is considered deleted.

* If a share 'share1' has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
'''That needs to be decided in this approach. A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

* As access-group tag definition is not static and is not kept independently. Now, With a large deployment and after many iterations of allow/deny,
this becomes hard for someone to remember, which share has what access-group tagging and what a tag composed of?

* Lets say 'share1' has 3 rules, share2 inherits from access-rules of 'share1'. Now, If there is a change in access-rules of 'share1' for some reason, after that point 'share1' and 'share2' will have different set of access-rule mapping. We can not trigger update on child shares(share2) as we are not keeping this parent child share mapping anywhere.

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

== Discussion ==
As has been discussed with bswartz the key points are as below:-

* Need to write spec fitting in formal template, as will be formalized by community soon.

* Access Group are envisioned to provide a grouping mechanism that can allow lets say a 100 shares an access to same host or 100 host can access a share.
Its many to many relationship. Architecture should be designed considering that access-group should be object immunal, it can be set of ip addresses or can
be set of users and so on.

* Adding an entry or deleting an entry to an access-group that's already mapped to a share, will affect all associated shares, either by applying or denying
as per requested entry operation.

* Design should allow later enhancements like, access-group should be able to refer to external entities like neutron security group or lets say a set of nova instances.
There should be a provision to say "allow access of this share to a nova instance uuid", wherein uuid is associated with an ip address.
Now, it may so happen that uuid changes its ip address in future, how will that be tackled?
Will neutron or nova inform such changes ? Or a polling required from manila side to obtain such information.. That needs to be seen.

* Access group can be asked to be "a union of previously formed access groups". An access group can contain all rules of two or more access-groups
that were formed earlier. A group can include other groups.

Manila/design/access groups

2016-04-11T08:04:52Z

Nidhi Mittal Hada: /* Thinking impact of 2nd approach.. */

Manila/design/access groups

2016-04-11T07:56:17Z

Nidhi Mittal Hada: /* Thinking impact of 2nd approach.. */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== 2nd Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database as compared to 1st approach.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope', same as the share,
its associated with. So no further means to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???
I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share1' ,AG1)

* If share is deleted and if its last share which was associated with a access-group, the access-group is considered deleted.

* If a share 'share1' has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
'''That needs to be decided in this approach. A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

* As access-group tag definition is not static and is not kept independently. Now, With a large deployment and after many iterations of allow/deny,
this becomes hard for someone to remember, which share has what access-group tagging and what a tag composed of?

* Lets say 'share1' has 3 rules, share2 inherits from access-rules of 'share1'. Now, If there is a change in access-rules of 'share1' for some reason, after that point
'share1' and 'share2' will have different set of access-rules mapping. We can not trigger update on child shares(share2) as we are not keeping this parent child share mapping
anywhere.

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-11T07:23:25Z

Nidhi Mittal Hada: /* Thinking impact of 2nd approach.. */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== 2nd Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database as compared to 1st approach.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope', same as the share,
its associated with. So no further means to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???
I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share1' ,AG1)

* If share is deleted and if its last share which was associated with a access-group, the access-group is considered deleted.

* If a share 'share1' has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
'''That needs to be decided in this approach. A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

* As access-group tag definition is not static and is not kept independently. Now, With a large deployment and after many iterations of allow/deny,
this becomes hard for someone to remember, which share has what access-group tagging and what a tag composed of?

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-11T07:21:53Z

Nidhi Mittal Hada: /* Thinking impact of 2nd approach.. */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== 2nd Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database as compared to 1st approach.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope', same as the share,
its associated with. So no further means to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???
I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share1' ,AG1)

* If share is deleted and if its last share which was associated with a access-group, the access-group is considered deleted.

* If a share 'share1' has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
'''That needs to be decided in this approach.'''
==== Actually, ==== '''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

* As access-group tag definition is not static and is not kept independently. Now, With a large deployment and after many iterations of allow/deny,
this becomes hard for someone to remember, which share has what access-group tagging and what a tag composed of?

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-07T05:40:12Z

Nidhi Mittal Hada: /* 2nd Alternative Approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== 2nd Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database as compared to 1st approach.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???
I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-05T06:42:16Z

Nidhi Mittal Hada: /* Thinking impact of 2nd approach.. */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== 2nd Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database as compared to 1st approach.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???

I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-05T06:41:00Z

Nidhi Mittal Hada: /* Alternative Approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== 2nd Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???

I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-05T06:38:08Z

Nidhi Mittal Hada: /* Simplifying More */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???

I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

== 3rd approach - Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-05T06:21:58Z

Nidhi Mittal Hada: /* Simplifying More */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???

I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

== Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing, --tag the interface, to inherit from.
manila access-inherit %some_new_share% --by-tag %tag% (********* Lets '''NOT''' have it **********)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets '''"only"''' have this)
There should be only api to inherit access from a share.

In such a case, we will allow, for first share like this...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records, for the share, in share_access_map table, '''without any tagging.'''
Next, a share, who wants similar access-scope, will do
manila access-inherit %some_new_share% --by-share %some_source_share%

* This solves the problem associated with tagging and trying to keep a static definition of a tag.

* This solves the problem of redundancy, as present in 1st approach.

* This has same problem, as in 2nd approach, of "not having an access-group after share-deletion".

* Once a share share1, has got a set of rules, it can be inherited by another share and rules-set that's inherited,
will be set of rules, associated "at that very moment" with share1. Things are dynamic. At some other moment in time,
some share might inherit separate set of rules, from same share, 'share1'.

* There will be no such api deny-access-rules where we can just say, '''deny group of rules, which we gave access together.'''
Deny-access will be similar to
manila access-deny %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6

Manila/design/access groups

2016-04-05T06:04:31Z

Nidhi Mittal Hada: /* Simplifying More : */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???

I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

== Simplifying More ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing the interface to inherit from --tag.
manila access-inherit %some_new_share% --by-tag %tag% (Lets not have it)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets only have this)
There should be only api to inherit access from a share.
In such a case, we will allow
For first share
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records for the share in share_access_map table without any tagging.
Next share who wants similar access-scope will do
manila access-inherit %some_new_share% --by-share %some_source_share%

Manila/design/access groups

2016-04-05T06:03:55Z

Nidhi Mittal Hada:

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???

I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

== Simplifying More : ==
Actually, As a tag doesn't have a individual independent identity, we can think of "NOT" providing the interface to inherit from --tag.
manila access-inherit %some_new_share% --by-tag %tag% (Lets not have it)
manila access-inherit %some_new_share% --by-share %some_source_share% (Lets only have this)
There should be only api to inherit access from a share.
In such a case, we will allow
For first share
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3,4.4.4.4,5.5.5.5,6.6.6.6
we will create multiple access-records for the share in share_access_map table without any tagging.
Next share who wants similar access-scope will do
manila access-inherit %some_new_share% --by-share %some_source_share%

Manila/design/access groups

2016-04-05T05:57:56Z

Nidhi Mittal Hada: /* Thinking impact of 2nd approach.. */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???

I think '''we can keep the new rule without tag.'''
Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay.
But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
* one that's coming from share1(2 rules)
* other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it?
That needs to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

Manila/design/access groups

2016-04-04T12:32:09Z

Nidhi Mittal Hada: /* Thinking impact of 2nd approach.. */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===

* This approach is lighter and less amount of redundancy in database.

* Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by old 'allow-access' api without any tag.
Now how will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
We can keep the new rule without tag.

Now, the next share share3 that inherits with --tag from share1 will get set of rules with combination (share1, tag1)
the next share share3 that inherits with --share from share1 will get all rules inclusive (share1, with tag) and (share1, without tag)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, one that's coming from share1(2 rules)
and other thats coming from share2(3 rules).
If a share3 is asking for rules same as tag AG1 what rules will be applied on it? That's need to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

Manila/design/access groups

2016-04-04T12:31:02Z

Nidhi Mittal Hada: /* Comparison with 1st approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Thinking impact of 2nd approach.. ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by old 'allow-access' api without any tag.
Now how will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
We can keep the new rule without tag.

Now, the next share share3 that inherits with --tag from share1 will get set of rules with combination (share1, tag1)
the next share share3 that inherits with --share from share1 will get all rules inclusive (share1, with tag) and (share1, without tag)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, one that's coming from share1(2 rules)
and other thats coming from share2(3 rules).
If a share3 is asking for rules same as tag AG1 what rules will be applied on it? That's need to be decided in this approach.
Actually
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.'''

Manila/design/access groups

2016-04-04T12:20:09Z

Nidhi Mittal Hada: /* Comparison with 1st approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by old 'allow-access' api without any tag.
Now how will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
We can keep the new rule without tag.

Now, the next share share3 that inherits with --tag from share1 will get set of rules with combination (share1, tag1)
the next share share3 that inherits with --share from share1 will get all rules inclusive (share1, with tag) and (share1, without tag)

* If share is deleted the access-group existed/associated with is, will be considered deleted.

* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules.
Now, access-group with 'AG1' tag - has got two separate set of access-rules, one that's coming from share1(2 rules)
and other thats coming from share2(3 rules).
If a share3 is asking for rules same as tag AG1 what rules will be applied on it ?

Manila/design/access groups

2016-04-04T12:08:38Z

Nidhi Mittal Hada: /* Comparison with 1st approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by old 'allow-access' api without any tag.
Now how will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
We can keep the new rule without tag.

Now, the next share share3 that inherits with --tag from share1 will get set of rules with combination (share1, tag1)
the next share share3 that inherits with --share from share1 will get all rules inclusive (share1, with tag) and (share1, without tag)

* If share is deleted the access-group associated will be considered deleted.. is it okay?

* If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-04T12:07:26Z

Nidhi Mittal Hada: /* Comparison with 1st approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by old 'allow-access' api without any tag.
Now how will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
We can keep the new rule without tag.
now a share3 which
the next share share3 that inherits with --tag from share1 will get set of rules with combination (share1, tag1)
the next share share3 that inherits with --share from share1 will get all rules inclusive (share1, with tag) and (share1, without tag)

* If share is deleted the access-group associated will be considered deleted.. is it okay?

* If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-04T12:05:30Z

Nidhi Mittal Hada: /* Comparison with 1st approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by old 'allow-access' api without any tag.
Now how will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
we can keep the new rule without tag.
now a share3 which
the next share share3 that inherits with --tag from share1 will get set of rules with combination (share1, tag1)
the next share share3 that inherits with --share from share1 will get all rules inclusive (share1, with tag) and (share1, without tag)

* If share is deleted the access-group associated will be considered deleted.. is it okay?

* If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-04T12:04:42Z

Nidhi Mittal Hada: /* Comparison with 1st approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by old 'allow-access' api without any tag.
Now how will we tackle such situation?
* Will we keep these new individual access_rule records without tag?
* Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
we can keep the new rule without tag.
now a share3 which
the next share share3 that inherits with --tag from share1 will get set of rules with combination (share1, tag1)
the next share share3 that inherits with --share from share1 will get all rules inclusive (share1, with tag) and (share1, without tag)

* If share is deleted the access-group associated will be considered deleted.. is it okay?

* If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-04T11:54:36Z

Nidhi Mittal Hada: /* Alternative Approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by indiviudal allow-access api.
Now how will we tackle such situation?
a)Will we keep these new individual access_rule records without tag?
b)Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?

* If share is deleted the access-group associated will be considered deleted.. is it okay?

* If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-04T11:51:06Z

Nidhi Mittal Hada: /* Alternative Approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries.
Instead by using a string type tag with share_access_map records, we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
manila access-inherit %some_new_share% --by-share %some_source_share%
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by indiviudal allow-access api.
Now how will we tackle such situation?
a)Will we keep these new individual access_rule records without tag?
b)Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?

* If share is deleted the access-group associated will be considered deleted.. is it okay?

* If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-04T11:44:31Z

Nidhi Mittal Hada: /* Comparison with 1st approach */

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries. Instead by using a string type tag with share_access_map records,
we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
manila access-inherit %some_new_share% --by-share %some_source_share%
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
* This approach is lighter and less amount of redundancy in database.

* Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.

* What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by indiviudal allow-access api.
Now how will we tackle such situation?
a)Will we keep these new individual access_rule records without tag?
b)Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?

* If share is deleted the access-group associated will be considered deleted.. is it okay?

* If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-04T11:38:11Z

Nidhi Mittal Hada:

== 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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

== 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.

== Alternative Approach ==
This approach suggests to tag/group share_access_map records by using a new field access_group_tag.
Here we do not create a separate entity access_group and access_group_entries. Instead by using a string type tag with share_access_map records,
we group a few entries together.

For first share that wants to allow a group of ip addresses/user the access.
cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%

After that any share that wants similar access will do
manila access-inherit %some_new_share% --by-share %some_source_share%
manila access-inherit %some_new_share% --by-tag %tag%

=== Comparison with 1st approach ===
1)This approach is lighter and less amount of redundancy in database.
2)Access-group being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.
3)What if 'share2' inherits all access_rules from 'share1' and now share1 adds a rule by indiviudal allow-access api.
Now how will we tackle such situation?
* a)Will we keep these new individual access_rule records without tag?
* b)Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag?
* c)If share is deleted the access-group associated will be considered deleted.. is it okay?
* d)If a share1 is allowed access to three ip addresses in AG1, now another share2 inherited all 3 rules with AG1 tag itself.
now, a deny access request comes, to delete one of the rule with share1.
Now, access-group with AG1 tag - has got two separate set of access-rules, one thats coming from share1(2 rules) and other thats coming from share2(3 rules).
If a share3 is asking for AG1's rules what rules will be applied on it ?

Manila/design/access groups

2016-04-01T11:33:57Z

Nidhi Mittal Hada:

Manila/design/access groups

2016-04-01T10:29:35Z

Nidhi Mittal Hada: /* How it works in different situations */

== 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== 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.

Manila/design/access groups

2016-04-01T10:24:47Z

Nidhi Mittal Hada: /* How it works in different situations */

== 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== 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)
is already applied' 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.

Manila/design/access groups

2016-04-01T10:23:15Z

Nidhi Mittal Hada: /* How it works in different situations */

== 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== 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)
is already applied' 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.

Manila/design/access groups

2016-04-01T10:02:49Z

Nidhi Mittal Hada: /* Challenges */

== 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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== 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(individual).'''

Ans: Nothing, set of access_rules for AG1, will be applied on share using add_rule field of
update_access().

'''Ques 2. What if the already applied rules are redundant to AG1 ?'''
'''lets say share1 has a access rule already applied to it as Share1 ->( user ,admin, rw).'''
Now AG1 contains an (user, admin, ro). API request comes as allow_access_group(share1, AG1).
Share1 is asked to map with AG1, what should happen?
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)
is already applied (this particular rule will be considered as applied already) 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_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer.
req2 also creates a access_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, 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
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>
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 access_map, we raise exception Not-Found and
continue to next access_entry.

Manila/design/access groups

2016-04-01T10:00:38Z

Nidhi Mittal Hada: /* How it works in different situations */

== 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 functionality, then rules will be sent to driver one by one only. Though access-group will allow user to
request access to bunch of ip addresses in one go, still backend will work on access-rules individually.

Proposed Object Relationships:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== 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(individual).'''

Ans: Nothing, set of access_rules for AG1, will be applied on share using add_rule field of
update_access().

'''Ques 2. What if the already applied rules are redundant to AG1 ?'''
'''lets say share1 has a access rule already applied to it as Share1 ->( user ,admin, rw).'''
Now AG1 contains an (user, admin, ro). API request comes as allow_access_group(share1, AG1).
Share1 is asked to map with AG1, what should happen?
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)
is already applied (this particular rule will be considered as applied already) 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_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer.
req2 also creates a access_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, 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
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>
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 access_map, we raise exception Not-Found and
continue to next access_entry.

Manila/design/access groups

2016-04-01T09:57:46Z

Nidhi Mittal Hada: /* How it works in different situations */

== 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 functionality, then rules will be sent to driver one by one only. Though access-group will allow user to
request access to bunch of ip addresses in one go, still backend will work on access-rules individually.

Proposed Object Relationships:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== 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(individual).'''

Ans: Nothing, set of access_rules for AG1, will be applied on share using add_rule field of
update_access().

'''Ques 2. What if the already applied rules are redundant to AG1 ?'''
'''lets say share1 has a access rule already applied to it as Share1 ->( user ,admin, rw).'''
Now AG1 contains an (user, admin, ro). API request comes as allow_access_group(share1, AG1).
Share1 is asked to map with AG1, what should happen?
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)
is already applied (this particular rule will be considered as applied already) 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_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer.
req2 also creates a access_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, 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
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>
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 access_map, we raise exception Not-Found and
continue to next access_entry.

Manila/design/access groups

2016-04-01T09:49:39Z

Nidhi Mittal Hada: /* How it works in different situations */

== 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 functionality, then rules will be sent to driver one by one only. Though access-group will allow user to
request access to bunch of ip addresses in one go, still backend will work on access-rules individually.

Proposed Object Relationships:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== 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(individual).'''

Ans: Nothing, set of access_rules for AG1, will be applied on share using add_rule field of
update_access().

'''Ques: What if the already applied rules are redundant to AG1 ?'''
'''lets say share1 has a access rule already applied to it as Share1 ->( user ,admin, rw).'''
Now AG1 contains an (user, admin, ro). API request comes as allow_access_group(share1, AG1).
Share1 is asked to map with AG1, what should happen?
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)
is already applied (this particular rule will be considered as applied already) 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: 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: 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: 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: 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_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer.
req2 also creates a access_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: 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.
in last two cases, share_access_group_mapping and many share_access_map entries would have been created!!!

'''Ques: What is purpose of access_rules_status and access_status_message field in share_instances table?'''
" access_status_message" field registers the error message from the driver layer.
" access_status_message" field in "share_instances" table - it does not show error messages
for above mentioned exceptions. if we get an error message back from driver, it gets registered in share_instances table.

'''Ques: 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>
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 access_map, we raise exception Not-Found and
continue to next access_entry.

Manila/design/access groups

2016-04-01T09:47:53Z

Nidhi Mittal Hada:

== 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 functionality, then rules will be sent to driver one by one only. Though access-group will allow user to
request access to bunch of ip addresses in one go, still backend will work on access-rules individually.

Proposed Object Relationships:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== How it works in different situations =====
'''Ques: Lets say , a user requests allow-access-group for (share1, AG1)
What if the share is already mapped to another access_group/access_rule(individual).'''

Ans: Nothing, set of access_rules for AG1, will be applied on share using add_rule field of
update_access().

'''Ques: What if the already applied rules are redundant to AG1 ?
lets say share1 has a access rule already applied to it as Share1 ->( user ,admin, rw).'''
Now AG1 contains an (user, admin, ro). API request comes as allow_access_group(share1, AG1).
Share1 is asked to map with AG1, what should happen?
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)
is already applied (this particular rule will be considered as applied already) 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: 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: 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: 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: 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_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer.
req2 also creates a access_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: 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.
in last two cases, share_access_group_mapping and many share_access_map entries would have been created!!!

'''Ques: What is purpose of access_rules_status and access_status_message field in share_instances table?'''
" access_status_message" field registers the error message from the driver layer.
" access_status_message" field in "share_instances" table - it does not show error messages
for above mentioned exceptions. if we get an error message back from driver, it gets registered in share_instances table.

'''Ques: 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>
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 access_map, we raise exception Not-Found and
continue to next access_entry.

Manila/design/access groups

2016-04-01T06:05:50Z

Nidhi Mittal Hada:

== 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 functionality, then rules will be sent to driver one by one only. Though access-group will allow user to
request access to bunch of ip addresses in one go, still backend will work on access-rules individually.

Proposed Object Relationships:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

* ==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== Design Decisions =====
'''#Ques: Lets say , a user requests '''allow-access-group for (share1, AG1)'''.
What if the "share" is already mapped to another access_group/access_rule(individual),'''
Ans: Nothing, set of access_rules for AG1, will be applied on share using add_rule field of
update_access().

'''Ques: What if the already applied rules are redundant to AG1 ?'''
lets say share1 has a access rule already applied to it as Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 contains an (user, admin, ro). API request comes as allow_access_group(share1, AG1).
Share1 is asked to map with AG1, what should happen?

Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
''We need to deny this rule first "to change its level if reqd".''

'''Ques: What if AG1 is made up of "n" rules, only one is redundant?'''
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'' and share_access_group_mapping
will be created

'''Ques: What if AG1 is made up of "n" rules, an error reported from backend for one of the rules?''
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: What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''Ques: 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_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer.
req2 also creates a access_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: 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.
in last two cases, share_access_group_mapping and many share_access_map entries would have been created!!!

'''Ques: What is purpose of access_rules_status and access_status_message field in share_instances table?'''
" access_status_message" field registers the error message from the driver layer.
" access_status_message" field in "share_instances" table - it does not show error messages
for above mentioned exceptions. if we get an error message back from driver, it gets registered in share_instances table.

'''Ques: 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>
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 access_map, we raise exception Not-Found and
continue to next access_entry.

Manila/design/access groups

2016-04-01T05:26:24Z

Nidhi Mittal Hada:

Manila Access Group
== 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_groups" will be created by user. Each "access_group" represents a bunch of homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level").
Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an "access-group", can be "either a set of ip addresses OR a set of users", that requires to be "allowed or denied" 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 rules can be 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 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.

Proposed Object Relationships:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Important Actions ==
{| class="wikitable"
|-
! 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 ====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

* ==== Deny Access Group ====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception Not-Found and
continue to next access_entry.

File:Allow access group (2).png

2016-03-31T12:27:06Z

Nidhi Mittal Hada: Nidhi Mittal Hada uploaded a new version of File:Allow access group (2).png

Manila/design/access groups

2016-03-31T12:20:44Z

Nidhi Mittal Hada:

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
manila access-group-allow <share> <access_group_id>
===== FlowChart =====
[[File : Allow_access_group_(2).png | center | 500px | Allow access group flow]]

=== * Deny Access Group to a share ===
manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception NotFound and
continue to next access_entry.

File:Allow access group (2).png

2016-03-31T12:07:50Z

Nidhi Mittal Hada:

Manila/design/access groups

2016-03-31T10:32:57Z

Nidhi Mittal Hada: /* Flowchart */

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
manila access-group-allow <share> <access_group_id>
===== FlowChart =====
[[File : Allow_access_group.png | center | 500px | Allow access group flow]]

=== * Deny Access Group to a share ===
manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 500px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception NotFound and
continue to next access_entry.

Manila/design/access groups

2016-03-31T10:32:30Z

Nidhi Mittal Hada: /* FlowChart */

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
manila access-group-allow <share> <access_group_id>
===== FlowChart =====
[[File : Allow_access_group.png | center | 500px | Allow access group flow]]

=== * Deny Access Group to a share ===
manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 100px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception NotFound and
continue to next access_entry.

Manila/design/access groups

2016-03-31T10:32:04Z

Nidhi Mittal Hada: /* Challenges */

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 500px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
manila access-group-allow <share> <access_group_id>
===== FlowChart =====
[[File : Allow_access_group.png | center | 100px | Allow access group flow]]

=== * Deny Access Group to a share ===
manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 100px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception NotFound and
continue to next access_entry.

Manila/design/access groups

2016-03-31T10:31:32Z

Nidhi Mittal Hada: /* Challenges */

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 1000px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
manila access-group-allow <share> <access_group_id>
===== FlowChart =====
[[File : Allow_access_group.png | center | 100px | Allow access group flow]]

=== * Deny Access Group to a share ===
manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 100px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception NotFound and
continue to next access_entry.

Manila/design/access groups

2016-03-31T10:31:00Z

Nidhi Mittal Hada: /* Challenges */

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 10000px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
manila access-group-allow <share> <access_group_id>
===== FlowChart =====
[[File : Allow_access_group.png | center | 100px | Allow access group flow]]

=== * Deny Access Group to a share ===
manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 100px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception NotFound and
continue to next access_entry.

Manila/design/access groups

2016-03-31T10:26:38Z

Nidhi Mittal Hada:

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 100px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
manila access-group-allow <share> <access_group_id>
===== FlowChart =====
[[File : Allow_access_group.png | center | 100px | Allow access group flow]]

=== * Deny Access Group to a share ===
manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 100px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules,
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).
Share1 is asked to map with AG1, what should happen?
Its same as case if we apply two redundant rules even without access-groups- we will get an exception access rule for (user, admin)
is already applied (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group.
We need to deny this rule first "to change its level if reqd".

'''What if AG1 is made up of "n" rules, only one is redundant?'''''Italic text''
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.

'''What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?'''''Italic text''
If there is an error reported from backend, then error will be registered in share_instance table.
"access_rules_status" will go in "error" state and "access_status_message" will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the requested share.

'''#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are:
AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically,
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives,
first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer.
Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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: What happens if an exception is raised for one of the access-rules in access-group?
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 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 come out
4)If share_instance is invalid one >> we come out
5)if access_rules_status is not active >> we come out
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions.
" access_status_message" field registers the error message from the driver layer.
in case we gets an error message back from driver, which tells rules it could not apply and why ?
and registers message in share_instance table.

'''Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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>
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 access_map, we raise exception NotFound and
continue to next access_entry.

Manila/design/access groups

2016-03-31T10:00:13Z

Nidhi Mittal Hada:

= Manila Access Groups =
== Applying Access Rules ==
=== Current approach ===
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, 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 (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, so that 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" 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 homogeneous "access_rules/access_entries".
(homogeneous here means rules of same "access_type & access_level")

Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time.
Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a 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 ===
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:-
[[File: DB_relationships.png| center | 100px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
Create an access group:-
manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

=== Add Access Group Entries in Access group ===
usage: manila access-group-entry-create <access_to> <access_group_id>

=== Allow Access Group to a share ===
Associating an access_group with a share - Allow access(cli)
usage: manila access-group-allow <share> <access_group_id>

===== FlowChart =====
[[File : Allow_access_group.png | center | 100px | Allow access group flow]]

=== * Deny Access Group to a share ===
usage: manila access-group-deny <share> <access_group_id>
===== Flowchart =====
[[File : Deny_access_group.png | center | 100px| deny access group flow]]

===== Design Decisions =====
'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
Will all rules for this share id - consolidating the ones from earlier mappings and this new one, be reapplied?

Ans: No, set of access_rules for this access_group only, will be applied on share.
===== Case1 Redundant Rules =====
If any access_rule from this access_group, is already applied on share(individually), due to access_allow api..
then excluding that access_rule, rest of the rules present in access_group will be applied on share.

===== Case2 Contradictory Rules =====
lets say share1 has a access rule already applied to it as
Access entry for Share1 ->( user ,admin, rw) (in share_access_map)
Now an AG1 with an (user, admin, ro) is created.
API request comes as allow_access(share1, AG1).

Share1 is asked to map with AG1, what should happen?

I think its same as case if we apply two contradictory rules even without access-groups- we will get an error access rule for user admin is already applied.
We need to deny it first to change it.
If there is an error reported from backend, then error will be registered in share_instance table.
access_rules_status will go in error state and access_status_message will contain the descriptive message.

'''# What if access group is already mapped to other shares and this is a new mapping.'''
Simply, rules from the access-group will be applied on the share.

'''# Ques: Two compatible access-groups mapping request got out of order before reaching backend driver.'''
Two api requests for two access_groups where two access rules are compatible,
came such as
AG1 has (user, admin, rw)
AG2 has (ip, 10.1.1.1, None)

2 Api requests come in this order
allow_access(share1, AG1) – Req1
allow_access(share1, AG2) – Req2

let’s say these request reach driver, out of order, that is backend driver receives, first Req2 then Req1.

https://etherpad.openstack.org/p/manila-access-groups-api-proposal line 324 says
**NOTE** the backend driver will always have to update the export rules to whatever the current state reflected in the database may be, to avoid race conditions with changes to the access group. For example, if someone makes two requests to the api and the messages arrive out of order to the driver, the end state of the first message will incorperate both changes and the second message will be a noop

That is It says :-
Req2 -> tells the driver to update export rules as per current state in DB.
Current state in DB is -> for share1 -> add two rules for AG1 and AG2 both.
Req1 -> for driver is noop

My Doubt :-
What I see is Req1 creates a access_mapping in db for share1 -> AG1 and passes that “only new” set of rules to driver layer.

Currently driver doesn’t work on current state of DB

def allow_access(self, context, share_instance_id, access_rules):
"""Allow access to some share instance."""
add_rules = [self.db.share_access_get(context, rule_id)
for rule_id in access_rules] >>

2. Adding/Deleting of several access rules - 'access_rules' contains
all access_rules, 'add_rules' and 'delete_rules' contain rules which
should be added/deleted.Driver can ignore rules in 'access_rules' and
apply only rules from 'add_rules' and 'delete_rules'.
Hence driver will only apply rules from req1 only.
My understanding is Req1 driver stage won’t apply req2’s rules on share.

Case3:- Access group contains multiple entries, where backend could apply only a few successfully, a few could not be applied.

Ques3: A share allow_access(share1, AG1)

AG1 has 3 access rule entries

[{ip, 1.1.1.1, none}, {ip, 2.2.2.2, None}, {ip, 3.3.3.3, None}]

Changes made to share_access_group_mapping table.

Backend could not apply 3rd rule successfully{ip, 3.3.3.3, None}

Result status will be marked in access_rules_status field, access_status_message will show the reason.

Case 4: if there are 4 rules to be applied as part of access_group, lets say 1 rule is redundant - does it try for 3 others ??
or a exception comes and it doesnt try further ?
These are such exceptions which come like
1)if share status is not AVAILABLE
2)If share_access entry already exists for this share ?
3)if access_level value requested for is not a valid value
4)If share_instance is invalid one
5)if access_rules_status is not active
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

Now need to decide
" access_status_message" field in "share_instances" table - will it express such messages for such exceptions?
OR
will it express the concern if driver has in applying those rules?e ex
If yes, in that case, it has to get a message back from driver, to know which rules it could not apply and why ?
How to get that status back from driver (Need to check)

Case5:- What if an access-group that contains 4 access_rules is applied on a share 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
1) manila access-group-allow <share-id> <access-group-id>
then
2)manila access-deny <share> <id>

Now some rules of this access-group are denied individually .. when we go to deny it

Manila/design/access groups

2016-03-31T09:40:03Z

Nidhi Mittal Hada: /* * Deny Access Group to a share */

Manila/design/access groups

2016-03-31T09:38:51Z

Nidhi Mittal Hada:

Manila/design/access groups

2016-03-31T09:06:24Z

Nidhi Mittal Hada: /* Action Flow */

<gallery>
Example.jpg|Caption1
Example.jpg|Caption2
</gallery>
== 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 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:-
[[File: DB_relationships.png| center | 100px| Object Relationship Diagram]]

== Action Flow ==
=== Create Access Group ===
Create an access group:-
stack@controller:~/devstack$ manila help access-group-create
usage: manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

Add a new access group.

Positional arguments:
<name> access group name.
<description> access group description.
<access_type> access type of access group.

Optional arguments:
--access-level <access_level>, --access_level <access_level>
Share access level ("rw" and "ro" access levels are
supported). Defaults to rw.
e.g.
manila access-group-create "AG2" "2nd" "user" --access_level "rw"

=== Add Access Group Entries in Access group ===
stack@controller:~/devstack$ manila help access-group-entry-create
usage: manila access-group-entry-create <access_to> <access_group_id>

Add a new access group entry.

Positional arguments:
<access_to> Value that defines access.
<access_group_id> Access Group ID.

manila --debug access-group-entry-create "demou" b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

=== Allow Access Group to a share ===
Associating an access_group with a share - Allow access(cli)
stack@controller:~/devstack$ manila help access-group-allow
usage: manila access-group-allow <share> <access_group_id>

Map access group to the share.

Positional arguments:
<share> ID of the NAS share to modify.
<access_group_id> ID of the access_group.
stack@controller:~/devstack$

manila --debug access-group-allow 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

===== Steps =====
1)Check if share_access_group_mapping doesn't exist for given share_id and access_group_id, then a record will be added to “share_access_group_mapping” table.
else the obtained record will be returned. End.

2)For each 'access_group_entry' in 'access_group_entries' for this access_group:
check sanity of each access_group_entry (if its already applied through access-allow api separately, OR if its a invalid access_level etc raise exception in such cases, continue the loop to next entry)
create a new "share_access_map" record - obtain it.
append a list of such access rules.

3)Pass 'access_rules_list' to be applied as a "bunch", to each of share_instance, associated with share.

===== FlowChart =====
[[File:: | Allow_access_group.png | center | Allow access group flow]]

===== Design Decisions =====
# What if The share is already mapped to another access_group already ??
All rules for this share id - consolidating the ones from earlier mappings and this new one will be reapplied???
No, set of access_rules for this access_group only, will be applied on share.
If any access_rule from this access_group, is already applied on share(individually), due to access_allow api..
then excluding that access_rule, rest of the rules present in access_group will be applied on share.

# What if access group is already mapped to other shares and this is a new mapping.
Simply, rules from the access-group will be applied on the share.

Need to check this (Pending)!!!

result_rules = [entries in access_group_id AG1] union [set of entries in share_access_map table for this share_id]
will be sent to driver like this.

self.driver.update_access(
context,
share_instance,
result_rules,>>>>>>>>>>>>>>>>>> all rules
add_rules=add_rules,>>>> rules present only in AG1
delete_rules=delete_rules,
share_server=share_server
)
If there is an error in applying rules, due to any reason, “access_rule_status” for share will reflect that with a descriptive error message.

=== * Deny Access Group to a share ===
stack@controller:~/devstack$ manila help access-group-deny
usage: manila access-group-deny <share> <access_group_id>
Unmap access group to the share.
Positional arguments:
<share> Name or ID of the NAS share to modify.
<access_group_id> ID of the access group to be unmapped.
stack@controller:~/devstack$
manila --debug access-group-deny 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

If it’s found in share_access_mapping, it will delete the mapping - will obtain all rules in the given access-group - and call update_access to delete these rules.
Action = deny_access_group
JSON Request
{
"deny_access_group":
{
"access_group": <Access-group-uuid>,
}
}

Flowchart for the process:-
<gallery>
Allow_access_group.png|Caption1
</gallery>

Manila/design/access groups

2016-03-31T08:54:42Z

Nidhi Mittal Hada: /* * Create Access Group */

<gallery>
Example.jpg|Caption1
Example.jpg|Caption2
</gallery>
== 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 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:-
[[File: DB_relationships.png| center | 100px| Object Relationship Diagram]]

== Action Flow ==
=== * Create Access Group ===
Create an access group:-
stack@controller:~/devstack$ manila help access-group-create
usage: manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

Add a new access group.

Positional arguments:
<name> access group name.
<description> access group description.
<access_type> access type of access group.

Optional arguments:
--access-level <access_level>, --access_level <access_level>
Share access level ("rw" and "ro" access levels are
supported). Defaults to rw.
e.g.
manila access-group-create "AG2" "2nd" "user" --access_level "rw"

=== * Add Access Group Entries in Access group ===
stack@controller:~/devstack$ manila help access-group-entry-create
usage: manila access-group-entry-create <access_to> <access_group_id>

Add a new access group entry.

Positional arguments:
<access_to> Value that defines access.
<access_group_id> Access Group ID.

manila --debug access-group-entry-create "demou" b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

=== * Allow Access Group to a share ===
Associating an access_group with a share - Allow access(cli)
stack@controller:~/devstack$ manila help access-group-allow
usage: manila access-group-allow <share> <access_group_id>

Map access group to the share.

Positional arguments:
<share> ID of the NAS share to modify.
<access_group_id> ID of the access_group.
stack@controller:~/devstack$

manila --debug access-group-allow 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

1)Check if share_access_group_mapping doesnt exist for given share_id and access_group_id. , then an entry will be added to“share_access_group_mapping” table.

2)For each 'access_group_entry' in 'access_group_entries' for this access_group:
check sanity of each access_group_entry (if its already applied through access-allow api separately, OR if its a invalid access_level etc raise exception in such cases, continue the loop to next entry)
create a new "share_access_map" record - obtain it.
append a list of such access rules.

3)Pass 'access_rules_list' to be applied as a "bunch", to each of share_instance, associated with share.

Flowchart link:-
https://wiki.openstack.org/w/images/8/85/Allow_access_group.png

** What if The share is already mapped to another access_group already ??
All rules for this share id - consolidating the ones from earlier mappings and this new one will be reapplied???
No, set of access_rules for this access_group only, will be applied on share.
If any access_rule from this access_group, is already applied on share(individually), due to access_allow api..
then excluding that access_rule, rest of the rules present in access_group will be applied on share.

** What if access group is already mapped to other shares and this is a new mapping.
Simply, rules from the access-group will be applied on the share.

Need to check this (Pending)!!!

result_rules = [entries in access_group_id AG1] union [set of entries in share_access_map table for this share_id]
will be sent to driver like this.

self.driver.update_access(
context,
share_instance,
result_rules,>>>>>>>>>>>>>>>>>> all rules
add_rules=add_rules,>>>> rules present only in AG1
delete_rules=delete_rules,
share_server=share_server
)
If there is an error in applying rules, due to any reason, “access_rule_status” for share will reflect that with a descriptive error message.

=== * Deny Access Group to a share ===
stack@controller:~/devstack$ manila help access-group-deny
usage: manila access-group-deny <share> <access_group_id>
Unmap access group to the share.
Positional arguments:
<share> Name or ID of the NAS share to modify.
<access_group_id> ID of the access group to be unmapped.
stack@controller:~/devstack$
manila --debug access-group-deny 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

If it’s found in share_access_mapping, it will delete the mapping - will obtain all rules in the given access-group - and call update_access to delete these rules.
Action = deny_access_group
JSON Request
{
"deny_access_group":
{
"access_group": <Access-group-uuid>,
}
}

Flowchart for the process:-
https://wiki.openstack.org/wiki/File:Deny_access_group.png

Manila/design/access groups

2016-03-31T08:51:21Z

Nidhi Mittal Hada: /* Current approach for access rules to a share */

<gallery>
Example.jpg|Caption1
Example.jpg|Caption2
</gallery>
== 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 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:-
[[File: DB_relationships.png| center | 100px| Object Relationship Diagram]]

== Action Flow ==
=== * Create Access Group ===
Create an access group:-
stack@controller:~/devstack$ manila help access-group-create
usage: manila access-group-create [--access-level <access_level>]
<name> <description> <access_type>

Add a new access group.

Positional arguments:
<name> access group name.
<description> access group description.
<access_type> access type of access group.

Optional arguments:
--access-level <access_level>, --access_level <access_level>
Share access level ("rw" and "ro" access levels are
supported). Defaults to rw.
e.g.
manila access-group-create "AG2" "2nd" "user" --access_level "rw"

=== * Add Access Group Entries in Access group ===
stack@controller:~/devstack$ manila help access-group-entry-create
usage: manila access-group-entry-create <access_to> <access_group_id>

Add a new access group entry.

Positional arguments:
<access_to> Value that defines access.
<access_group_id> Access Group ID.

manila --debug access-group-entry-create "demou" b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

=== * Allow Access Group to a share ===
Associating an access_group with a share - Allow access(cli)
stack@controller:~/devstack$ manila help access-group-allow
usage: manila access-group-allow <share> <access_group_id>

Map access group to the share.

Positional arguments:
<share> ID of the NAS share to modify.
<access_group_id> ID of the access_group.
stack@controller:~/devstack$

manila --debug access-group-allow 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

1)Check if share_access_group_mapping doesnt exist for given share_id and access_group_id. , then an entry will be added to“share_access_group_mapping” table.

2)For each 'access_group_entry' in 'access_group_entries' for this access_group:
check sanity of each access_group_entry (if its already applied through access-allow api separately, OR if its a invalid access_level etc raise exception in such cases, continue the loop to next entry)
create a new "share_access_map" record - obtain it.
append a list of such access rules.

3)Pass 'access_rules_list' to be applied as a "bunch", to each of share_instance, associated with share.

Flowchart link:-
https://wiki.openstack.org/w/images/8/85/Allow_access_group.png

** What if The share is already mapped to another access_group already ??
All rules for this share id - consolidating the ones from earlier mappings and this new one will be reapplied???
No, set of access_rules for this access_group only, will be applied on share.
If any access_rule from this access_group, is already applied on share(individually), due to access_allow api..
then excluding that access_rule, rest of the rules present in access_group will be applied on share.

** What if access group is already mapped to other shares and this is a new mapping.
Simply, rules from the access-group will be applied on the share.

Need to check this (Pending)!!!

result_rules = [entries in access_group_id AG1] union [set of entries in share_access_map table for this share_id]
will be sent to driver like this.

self.driver.update_access(
context,
share_instance,
result_rules,>>>>>>>>>>>>>>>>>> all rules
add_rules=add_rules,>>>> rules present only in AG1
delete_rules=delete_rules,
share_server=share_server
)
If there is an error in applying rules, due to any reason, “access_rule_status” for share will reflect that with a descriptive error message.

=== * Deny Access Group to a share ===
stack@controller:~/devstack$ manila help access-group-deny
usage: manila access-group-deny <share> <access_group_id>
Unmap access group to the share.
Positional arguments:
<share> Name or ID of the NAS share to modify.
<access_group_id> ID of the access group to be unmapped.
stack@controller:~/devstack$
manila --debug access-group-deny 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

If it’s found in share_access_mapping, it will delete the mapping - will obtain all rules in the given access-group - and call update_access to delete these rules.
Action = deny_access_group
JSON Request
{
"deny_access_group":
{
"access_group": <Access-group-uuid>,
}
}

Flowchart for the process:-
https://wiki.openstack.org/wiki/File:Deny_access_group.png