[
https://issues.apache.org/jira/browse/YARN-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483812#comment-14483812
]
Zhijie Shen commented on YARN-3391:
-----------------------------------
bq. let's continue the discussion on a separated JIRA for figuring it out later.
Agree. Let's unblock this Jira which will unblock the writer implementation
consequently. I filed YARN-3461 to continue the defaults discussion there.
bq. I just wanted to add my 2 cents that this is something we already see and
experience with hRaven so it's not theoretical.
Sangjin, thanks for sharing the use case in hRaven. It's helpful to understand
the proper defaults. To generalize it, we need to consider different use cases
such as adhoc applications only. Shall we continue the discussion on YARN-3461?
bq. As I mentioned earlier, it should be useful for developers
I make use of Sangjin's previous comments to add some inline code comments
about their definitions in TimelineCollectorContext.
> Clearly define flow ID/ flow run / flow version in API and storage
> ------------------------------------------------------------------
>
> Key: YARN-3391
> URL: https://issues.apache.org/jira/browse/YARN-3391
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Zhijie Shen
> Assignee: Zhijie Shen
> Attachments: YARN-3391.1.patch, YARN-3391.2.patch, YARN-3391.3.patch
>
>
> To continue the discussion in YARN-3040, let's figure out the best way to
> describe the flow.
> Some key issues that we need to conclude on:
> - How do we include the flow version in the context so that it gets passed
> into the collector and to the storage eventually?
> - Flow run id should be a number as opposed to a generic string?
> - Default behavior for the flow run id if it is missing (i.e. client did not
> set it)
> - How do we handle flow attributes in case of nested levels of flows?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
