[
https://issues.apache.org/jira/browse/YARN-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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
submission.
* 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
granted.
* Helper methods to aid working with the registry in clients and
AMs/containers. See
{{org.apache.hadoop.yarn.registry.client.binding.RegistryOperationUtils}}
> 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
(v6.3.4#6332)
