[ 
https://issues.apache.org/jira/browse/YARN-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14376169#comment-14376169
 ] 

Zhijie Shen commented on YARN-3040:
-----------------------------------

bq.  It sounds not quite scalable if we have one client for each app in the 
RM...

In RM/NM, I think we can and we should implement a wrapper layer, which may 
contain multiple applications, to have delegator  to write the data for 
multiple applications.

bq. One most significant advantage to have run ids as integers is we can easily 
sort all existing runs for one flow in ascending or descending order. This 
might be a solid use case in general?

I can see the benefit. For example, if it represents the timestamp, we can 
filter the flow runs and say give me the runs in the last 5 mins. But my 
concern is whether it's the general way to let user to describe a run.

bq. Hmm, I didn't think the version as part of the flow id.

I can understand this particular case described above. Like my prior comment 
about flow run ID, my concern is whether flow/version/run's explicit hierarchy 
is so general to capture most use cases. IMHO, by nature, the hierarchy is the 
tree of flows, and a flow can be the flow of flows or the flow of apps. 
However, if other users just want to use one level of flow, version/run info 
seems to be redundant. On the other side, if use the flow recursion structure, 
it's elastic to have flow levels from one to many. We can treat the first level 
as the flow, the second as version and third and run. I don't have expertise 
knowledge about workflow such as Oozie, but just want to think out my concern 
loudly. That said, if flow/version/run is the general description of a flow, I 
agree we should pass in these three env vars together and separately.

bq. Mostly fine, but I have some concerns about rolling upgrades.
bq. I'm still not sure why it would make sense to have different logical 
cluster id's every time the RM/cluster restarts. 

I meant the admin can configure a cluster ID explicitly, which won't be 
appended with the timestamp. I added it for the default value to distinguish 
the clusters that are started by you and me, but I think about it again, and it 
seems that RM restarting problem makes sense. I'll change the default not to 
append timestamp.


> [Data Model] Make putEntities operation be aware of the app's context
> ---------------------------------------------------------------------
>
>                 Key: YARN-3040
>                 URL: https://issues.apache.org/jira/browse/YARN-3040
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Sangjin Lee
>            Assignee: Zhijie Shen
>         Attachments: YARN-3040.1.patch, YARN-3040.2.patch
>
>
> Per design in YARN-2928, implement client-side API for handling *flows*. 
> Frameworks should be able to define and pass in all attributes of flows and 
> flow runs to YARN, and they should be passed into ATS writers.
> YARN tags were discussed as a way to handle this piece of information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to