[
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)
