[incubator-yunikorn-site] branch master updated: [YUNIKORN-652] Update ACL doc (#53)

[ww...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

wwei pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-yunikorn-site.git


The following commit(s) were added to refs/heads/master by this push:
     new 62a32ee  [YUNIKORN-652] Update ACL doc (#53)
62a32ee is described below

commit 62a32eed4b88472a399e460a8e3d348f31b1da7a
Author: Amit Sharma <60...@users.noreply.github.com>
AuthorDate: Tue May 11 15:53:07 2021 -0700

    [YUNIKORN-652] Update ACL doc (#53)
---
 docs/user_guide/acls.md | 30 +++---------------------------
 1 file changed, 3 insertions(+), 27 deletions(-)

diff --git a/docs/user_guide/acls.md b/docs/user_guide/acls.md
index 8f41a80..c1fd7f2 100644
--- a/docs/user_guide/acls.md
+++ b/docs/user_guide/acls.md
@@ -22,9 +22,8 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-:::caution
-User information is currently not passed to the core scheduler from the kubernetes shim.
-Therefore, the recommendation is to use the wildcard ACL on the root queue for now as per the default configuration.
+:::info
+User information is passed to the core scheduler from the kubernetes shim using the methodology defined [here](usergroup_resolution)
 :::
 
 ## Usage
@@ -117,27 +116,4 @@ If a check matches the ACL allows access and checking is stopped.
 If none of the checks match the ACL denies access.
 
 ## User and Group information
-ACLs require the user's name and group membership.
-User information must be provided by the shims to the core scheduler.
-The current expectation is that the shims only provide the user information and leave the group information empty.
-
-User information is passed around in the scheduler as a combined user and groups object.
-These objects are cached to allow fast lookup and minimise resolution of the groups.
-
-Based on the fact that the shims do not have to provide group information the core has the possibility to resolve the group memberships.
-Group membership resolution is pluggable, see [resolution](#resolution) below.
-If the resolution of the groups of a user fails the result is still cached with a shortened lifetime.
-Users resolution is cached, negatively and positively, per partition.
-Users resolution like many other configs can differ between partition.
-
-### Resolution
-Groups do not have to be part of provided user and group object.
-When the object is added to the cache the groups are automatically resolved based on the resolution that is configured.
-The resolver which is linked to the cache can be set per partition.
-
-The default group resolver is "no resolver".
-This resolver just echos the user name and a primary group with the same name as the user.
-
-Other resolvers are:
-* OS resolver
-* test resolver
+For User & Group resolution, please follow instructions defined [here](usergroup_resolution)