hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4356) ensure the timeline service v.2 is disabled cleanly and has no impact when it's turned off
Date Wed, 09 Dec 2015 05:13:11 GMT

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

Sangjin Lee commented on YARN-4356:
-----------------------------------

Thanks for your review [~gtCarrera9].

bq. I noticed in some files we're verifying v2 in a hard-coded fashion (version == 2). Why
do we still need this especially when we have timelineServiceV2Enabled()?

The only reason for them is because timelineServiceV2Enabled() is timelineServiceEnabled()
+ (timelineServiceVersion == 2). In those cases, timelineServiceEnabled() was already checked.
Thus, as a (small) optimization I just checked the version directly. Having said that, I'm
comfortable with changing them to call timelineServiceV2Enabled() even though it may check
timelineServiceEnabled() one extra time. I'll make those changes.

bq. That is, if the timeline-service.version is set to 2.x in future, are the applications
allowed to use other versions of ATS?

It should be possible in principle with the assumption that some compatibility mechanism is
in place so an old API invocation can succeed. The config is there to discover what's running
on the cluster. If there is a compatibility mechanism, applications may invoke a different
API (it's entirely up to them at that point).

bq. ApplicationMaster, function names "...OnNewTimelineService" can be more specific like
"...V2"?

Sounds good. I didn't rename methods as part of this work, but let me see if I can rename
them to use "v2".

bq. ContainerManagerImpl, I just want to double check one behavior: the SMP is enabled for
the NM only when timeline version is v2 and SMP is enabled in the config? What about v1.x
versions? If this is a v2 only feature, shall we clarify that in the log message?

The v.1 behavior should be essentially the same as today. The existing v.1 behavior is to
check TIMELINE_SERVICE_ENABLED and then RM_SYSTEM_METRICS_PUBLISHER_ENABLED. You'll see that
the current patch checks TIMELINE_SERVICE_ENABLED, TIMELINE_SERVICE_VERSION == 1, and RM_SYSTEM_METRICS_PUBLISHER_ENABLED.
I do see that it's checking strictly for version = 1. I'll change it to check for version
< 2 so it can match 1.5 as well.

> ensure the timeline service v.2 is disabled cleanly and has no impact when it's turned
off
> ------------------------------------------------------------------------------------------
>
>                 Key: YARN-4356
>                 URL: https://issues.apache.org/jira/browse/YARN-4356
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Sangjin Lee
>            Assignee: Sangjin Lee
>            Priority: Critical
>              Labels: yarn-2928-1st-milestone
>         Attachments: YARN-4356-feature-YARN-2928.002.patch, YARN-4356-feature-YARN-2928.003.patch,
YARN-4356-feature-YARN-2928.poc.001.patch
>
>
> For us to be able to merge the first milestone drop to trunk, we want to ensure that
once disabled the timeline service v.2 has no impact from the server side to the client side.
If the timeline service is not enabled, no action should be done. If v.1 is enabled but not
v.2, v.1 should behave the same as it does before the merge.



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

Mime
View raw message