Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.5.0, 2.4.1
-
None
-
None
Description
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.
Attachments
Attachments
Issue Links
- is depended upon by
-
SLIDER-365 slider "resolve" command to retrieve service record
- Resolved
-
YARN-896 Roll up for long-lived services in YARN
- Open
-
SLIDER-149 Support a YARN service registry
- Resolved
- is related to
-
HADOOP-11117 UGI HadoopLoginModule doesn't catch & wrap all kerberos-related exceptions
- Resolved
-
HADOOP-11111 MiniKDC to use locale EN_US for case conversions
- Closed
- relates to
-
YARN-4758 Enable discovery of AMs by containers
- Open
-
YARN-6413 FileSystem based Yarn Registry implementation
- Resolved
-
YARN-1143 Restrict the names that apps and types can have
- Closed
1.
|
distributed shell & tests to use registry | Open | Steve Loughran | |
2.
|
Provide Read Write REST view of YARN registry and client compatible with existing Registry API | Open | Unassigned | |
3.
|
TTL for YARN Registry SRV records | Open | Unassigned | |
4.
|
Collision-free unique bindings & refresh APIs for service records | Open | Unassigned | |
5.
|
TTL & identity aware read cache for the SRV records | Open | Unassigned |