[
https://issues.apache.org/jira/browse/YARN-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353872#comment-14353872
]
Sangjin Lee commented on YARN-2928:
-----------------------------------
A couple of more comments on the plan:
- I think the metrics API should be part of phase 2 since we will handle
aggregation
- It's a small item, but we should make the per-node aggregator a standalone
daemon part of phase 2
Speaking of "aggregator", the word "aggregation/aggregator" is now getting
quite overloaded. Originally it meant "rolling up metrics to parent entities".
Now it's really used in two quite different contexts. For example, the
TimelineAggregator classes have little to do with that original meaning. I'm
not quite sure what aggregation means in that context, although, I know, I
know, I said +1 to the name TimelineAggregator. :) Should we clear up this
confusion? IMO, we should stick with the original meaning of aggregation when
we talk about aggregation. For TimelineAggregator, perhaps we could rename it
to TimelineReceiver or another name?
> Application Timeline Server (ATS) next gen: phase 1
> ---------------------------------------------------
>
> Key: YARN-2928
> URL: https://issues.apache.org/jira/browse/YARN-2928
> Project: Hadoop YARN
> Issue Type: New Feature
> Components: timelineserver
> Reporter: Sangjin Lee
> Assignee: Sangjin Lee
> Priority: Critical
> Attachments: ATSv2.rev1.pdf, ATSv2.rev2.pdf, Data model proposal
> v1.pdf, Timeline Service Next Gen - Planning - ppt.pptx
>
>
> We have the application timeline server implemented in yarn per YARN-1530 and
> YARN-321. Although it is a great feature, we have recognized several critical
> issues and features that need to be addressed.
> This JIRA proposes the design and implementation changes to address those.
> This is phase 1 of this effort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
