[jira] [Commented] (YARN-1222) Make improvements in ZKRMStateStore for fencing

["Karthik Kambatla (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/YARN-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812663#comment-13812663 ] 

Karthik Kambatla commented on YARN-1222:
----------------------------------------

bq. deleteWithRetries() - The new logic does not seem identical to the older logic.
Good catch! It is not identical, but should have the same effect. Instead of using a ZKAction that does both exist() and delete(), the second patch was doing exist first (with retries) and then delete which can lead to funny behavior. Hence, the return null.

bq. why do we do an exists check instead of catching the NoNodeException after calling delete directly?
Agree deleting and catching NoNodeException makes more sense. The exists() followed by delete() comes from earlier patches on YARN-353, and I am not sure the reasoning behind it. We don't seem to be using the watch anywhere. The updated patch (-3.patch) adopts this approach.

bq. Should this method only change the ACL's pertaining to other RM instances and not every ACL on the znode? Alternatively, if the assumption is that the root znode etc are manipulated only by the RM's then can we simply remove all older ACL's and set a new ACL for the current RM.
Only the RMs manipulate the znode structure. Here, we are using the ZKStoreACLs to generate the ZKRootNodeACLs. IIUC, the ZKStoreACLs define who has access to the store. That could be used to define the users that can run the RM with ZKStateStore; an example could be that only adminuser is allowed. The patch provides adminuser as much access on the ZKRootNode as possible, removing create-delete permissions. In addition to that, it gives exclusive create-delete perms to the RM on ZKRootNode. I think this is required if we want to support this behavior even for an ACL list where say each element gives one user access to run the RM. One extreme case could be two RMs running - each started by a different user with both users being allowed by the ACLs. 

Does that sound reasonable? Should we handle it any other way?

> Make improvements in ZKRMStateStore for fencing
> -----------------------------------------------
>
>                 Key: YARN-1222
>                 URL: https://issues.apache.org/jira/browse/YARN-1222
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Bikas Saha
>            Assignee: Karthik Kambatla
>         Attachments: yarn-1222-1.patch, yarn-1222-2.patch, yarn-1222-3.patch
>
>
> Using multi-operations for every ZK interaction. 
> In every operation, automatically creating/deleting a lock znode that is the child of the root znode. This is to achieve fencing by modifying the create/delete permissions on the root znode.



--
This message was sent by Atlassian JIRA
(v6.1#6144)