Sangjin Lee commented on YARN-4224:

Sorry I am catching up with the discussion. Just to put my opinions on some of 
the questions raised so far.

Regarding omitting some part of the path in the hierarchical form of the URL:
bq. Sangjin Lee did you mean providing shortcuts to thing like applications 
(instead of cluster, user, flow, flowrun, app, we can directly have cluster and 
Yes, for example, when you query for things like all apps in a flow run, it is 
possible to omit things like "user" as it can be inferred from the rest of the 
information. Although the path is /cluster/user/flow/flow-run-id/apps, I was 
hoping one could do /cluster/flow/flow-run-id/apps and the server will accept 
it as long as it can infer the missing path from the rest of the context. The 
UID form would have to specify all parts of the information with no exception 
however to eliminate any ambiguity. I hope that answers the question.

Regarding creating the UID, I think we still need to make a call on whether to 
make the UID composition a public protocol. If we do, then potentially we don't 
need to return anything and don't have to worry about in which layer in the 
server-side it will be composed.

On a related note, I'm leaning against making the UID composition configurable. 
I don't see a whole lot of practical need to customize UID composition, and it 
will only cause more confusion especially when a user/client deals with 
multiple clusters.

On specifying the entity type along with the entity's UID, I think it would 
definitely better if not required. My memory is bit hazy on this, but I think 
there is no hard guarantee that an entity id is unique even within a parent 
yarn app. Entity id's are essentially up to whoever writes them, and they may 
choose degenerate id's. I think we always said only the tuple of (entity type, 
entity id) is unique within an application, right? So, what is the required 
info for uniquely locating an entity? Entity type, and entity id are needed, 
but how about the context? App id? Any flow contexts?

> Change the ATSv2 reader side REST interface to conform to current REST APIs' 
> in YARN
> ------------------------------------------------------------------------------------
>                 Key: YARN-4224
>                 URL: https://issues.apache.org/jira/browse/YARN-4224
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Varun Saxena
>            Assignee: Varun Saxena
>              Labels: yarn-2928-1st-milestone
>         Attachments: YARN-4224-YARN-2928.01.patch, 
> YARN-4224-feature-YARN-2928.wip.02.patch

This message was sent by Atlassian JIRA

Reply via email to