Steve Loughran updated YARN-913:
    Attachment: YARN-913-009.patch

Revised patch

A key change is * support for kerberos digest (id:pass) ACLs in paths under 
user accounts. A user may request that all nodes/records created in a session 
add specific id:pass access to the nodes; these are translated into 
full-access-ACL entries. 

Why do this? It allows a user to give a long-running service the ability to 
manipulate part of the service registry —i.e. its own record and below— without 
having to worry about token expiry.  It's not mandatory for long running 
services to do this; they can go the credential route if they want...this just 
makes it an option. In particular, it allows containers to add records without 
needing any credentials, even if the AM bootstraps the registration from one 
supplied at launch time.

* factory to create kerberos, anonymous and user:pass accessors to the registry
* RM automatically creates user dir with write access for the the user on app 
* Security model tested in *much* more depth. Specifically, all those different 
levels of access are tested to make sure that extra rights are not being 
* Helper methods to aid working with the registry in clients and 
AMs/containers. See 

> Add a way to register long-lived services in a YARN cluster
> -----------------------------------------------------------
>                 Key: YARN-913
>                 URL: https://issues.apache.org/jira/browse/YARN-913
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: api, resourcemanager
>    Affects Versions: 2.5.0, 2.4.1
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>         Attachments: 2014-09-03_Proposed_YARN_Service_Registry.pdf, 
> 2014-09-08_YARN_Service_Registry.pdf, RegistrationServiceDetails.txt, 
> YARN-913-001.patch, YARN-913-002.patch, YARN-913-003.patch, 
> YARN-913-003.patch, YARN-913-004.patch, YARN-913-006.patch, 
> YARN-913-007.patch, YARN-913-008.patch, YARN-913-009.patch, yarnregistry.pdf, 
> yarnregistry.tla
> In a YARN cluster you can't predict where services will come up -or on what 
> ports. The services need to work those things out as they come up and then 
> publish them somewhere.
> Applications need to be able to find the service instance they are to bond to 
> -and not any others in the cluster.
> Some kind of service registry -in the RM, in ZK, could do this. If the RM 
> held the write access to the ZK nodes, it would be more secure than having 
> apps register with ZK themselves.

This message was sent by Atlassian JIRA

Reply via email to