Steve Loughran commented on YARN-3372:

what naming scheme do you propose? SLIDER uses that of (yarn-app-class, 
yarn-app-name) with the implicit username, and rely on a policy of "one unique 
name". I guess that gets confused over time, even if enforced. Something like a 
uuid would be good -though it needs to valid DNS name for future DNS support., 
such as {{uuid0005455feaf}}.

For YARN-launched apps, the yarn app ID is guaranteed to be unique for the 
lifespan of the RM/cluster; attempt ID across attempts

> Collision-free unique bindings & refresh APIs for service records
> -----------------------------------------------------------------
>                 Key: YARN-3372
>                 URL: https://issues.apache.org/jira/browse/YARN-3372
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>            Reporter: Gopal V
> The current bind() operation binds to a hard entry name for the service 
> record, which makes it impossible for a truly distributed application without 
> a centralized service to register without pre-determined naming conventions.
> The uniqueness does not need to guarantee ordering or any other leakage of 
> abstractions, merely that each bind() returns a unique path the record was 
> bound to. And that the TTL refresh can periodically update that exact record 
> as an active API.
> These are state-less auto-configuration mechanisms inspired by the IPv6 
> improvements over DNS for resolution. Instead of relying ICMPv6, this uses 
> the registry to keep a collective memory of unique identities to which 
> endpoints are delegated to.
> This is only obliquely related to the Slider registration as even those do 
> not track the generational ids for restarted daemons from the same 
> container-id.

This message was sent by Atlassian JIRA

Reply via email to