[
https://issues.apache.org/jira/browse/YARN-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032243#comment-15032243
]
Sangjin Lee commented on YARN-3862:
-----------------------------------
Thanks Allen for clarifying the issue.
It's great that there are a lot of improvements made for the build in the
trunk, but this does pose a pretty interesting challenge for branch
development. In short, it's just not realistic for a branch development team to
rebase with trunk on a constant basis. We do want to stay as close to the trunk
as possible, but it is definitely an overhead that takes a full day or two of
downtime to resolve issues. And in the latest rebase, we're still smarting from
the git branch lockdown issue.
As you suggested, a compromise here may be cherry-picking only those build
changes from trunk. However, it's not without issues there. It's about always
being able to isolate the build changes cleanly. For example, I'm not
comfortable cherry-picking all of pom.xml changes. There can be pom changes
that are not related to the build fixes and also those that are part of much
bigger changes. If we had to cherry-pick them, I'd rather do a full rebase.
Also, I hope this still preserves our ability to do a simple "git rebase trunk"
when we do a regular rebase.
I see the following 3 commits to dev-support since our last rebase:
{noformat}
commit 0ca8df716a1bb8e7f894914fb0d740a1d14df8e3
Author: Haohui Mai <whe...@apache.org>
Date: Thu Nov 12 10:17:41 2015 -0800
HADOOP-12562. Make hadoop dockerfile usable by Yetus. Contributed by Allen
Wittenauer.
commit 123b3db743a86aa18e46ec44a08f7b2e7c7f6350
Author: Tsuyoshi Ozawa <oz...@apache.org>
Date: Mon Oct 26 23:17:45 2015 +0900
HADOOP-12513. Dockerfile lacks initial 'apt-get update'. Contributed by
Akihiro Suda.
commit 39581e3be2aaeb1eeb7fb98b6bdecd8d4e3c7269
Author: Vinayakumar B <vinayakum...@apache.org>
Date: Tue Oct 13 19:00:08 2015 +0530
HDFS-9139. Enable parallel JUnit tests for HDFS Pre-commit (Contributed by
Chris Nauroth and Vinayakumar B)
{noformat}
And I think we can cherry-pick HADOOP-12513 and HADOOP-12562. Does that sound
right? Do we need more?
> Support for fetching specific configs and metrics based on prefixes
> -------------------------------------------------------------------
>
> Key: YARN-3862
> URL: https://issues.apache.org/jira/browse/YARN-3862
> 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-3862-YARN-2928.wip.01.patch,
> YARN-3862-YARN-2928.wip.02.patch, YARN-3862-feature-YARN-2928.04.patch,
> YARN-3862-feature-YARN-2928.wip.03.patch
>
>
> Currently, we will retrieve all the contents of the field if that field is
> specified in the query API. In case of configs and metrics, this can become a
> lot of data even though the user doesn't need it. So we need to provide a way
> to query only a set of configs or metrics.
> As a comma spearated list of configs/metrics to be returned will be quite
> cumbersome to specify, we have to support either of the following options :
> # Prefix match
> # Regex
> # Group the configs/metrics and query that group.
> We also need a facility to specify a metric time window to return metrics in
> a that window. This may be useful in plotting graphs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
