FAQ
Hello,

I struggle with a migration between yarn and mapred v1. Therefore I need to
switch the client config from yarn to mapred.

My workflow is (using the Cloudera Manager):
1) stop yarn1
2) start mapred1
3) deploy client configuration

At this point the Cloudera Manager deploys the correct configuration for
the mapred service, but the yarn configuration still is there.
Due to the higher priority of yarn, the mapred config is not used by the
systems:

$ update-alternatives --display hadoop-conf
hadoop-conf - auto mode
link currently points to /etc/hadoop/conf.cloudera.yarn1
/etc/hadoop/conf.cloudera.hdfs1 - priority 90
/etc/hadoop/conf.cloudera.mapreduce1 - priority 91
/etc/hadoop/conf.cloudera.yarn1 - priority 92
/etc/hadoop/conf.empty - priority 10
Current 'best' version is '/etc/hadoop/conf.cloudera.yarn1'.

Why is the client configuration not undeployed automatically when the yarn1
service is stopped / the mapred1 service is started? Is it a problem
restricted to the Ubuntu versions of CDH?

Is there a way to undeploy the client configuration "by hand" for yarn from
within the Cloudera Manager or do I need to write a script for it?

kr,
Till

Search Discussions

  • Philip Langdale at Oct 30, 2012 at 5:33 pm
    You can't completely undeploy, but you can reduce the yarn priority (or
    increase
    the mapreduce priority) and then when you redeploy the one you changed, it
    will cause alternatives to readjust the 'best' version.

    --phil


    On 30 October 2012 08:53, tmac wrote:

    Hello,

    I struggle with a migration between yarn and mapred v1. Therefore I need
    to switch the client config from yarn to mapred.

    My workflow is (using the Cloudera Manager):
    1) stop yarn1
    2) start mapred1
    3) deploy client configuration

    At this point the Cloudera Manager deploys the correct configuration for
    the mapred service, but the yarn configuration still is there.
    Due to the higher priority of yarn, the mapred config is not used by the
    systems:

    $ update-alternatives --display hadoop-conf
    hadoop-conf - auto mode
    link currently points to /etc/hadoop/conf.cloudera.yarn1
    /etc/hadoop/conf.cloudera.hdfs1 - priority 90
    /etc/hadoop/conf.cloudera.mapreduce1 - priority 91
    /etc/hadoop/conf.cloudera.yarn1 - priority 92
    /etc/hadoop/conf.empty - priority 10
    Current 'best' version is '/etc/hadoop/conf.cloudera.yarn1'.

    Why is the client configuration not undeployed automatically when the
    yarn1 service is stopped / the mapred1 service is started? Is it a problem
    restricted to the Ubuntu versions of CDH?

    Is there a way to undeploy the client configuration "by hand" for yarn
    from within the Cloudera Manager or do I need to write a script for it?

    kr,
    Till

  • Tmac at Oct 30, 2012 at 5:44 pm
    OK, that's what I expected and what I did during the last hour.

    But thanks a lot for the fast reply! :)

    kr
    Till

    On Tuesday, October 30, 2012 6:27:29 PM UTC+1, Philip Langdale wrote:

    You can't completely undeploy, but you can reduce the yarn priority (or
    increase
    the mapreduce priority) and then when you redeploy the one you changed, it
    will cause alternatives to readjust the 'best' version.

    --phil



    On 30 October 2012 08:53, tmac <till.sto...@gmail.com <javascript:>>wrote:
    Hello,

    I struggle with a migration between yarn and mapred v1. Therefore I need
    to switch the client config from yarn to mapred.

    My workflow is (using the Cloudera Manager):
    1) stop yarn1
    2) start mapred1
    3) deploy client configuration

    At this point the Cloudera Manager deploys the correct configuration for
    the mapred service, but the yarn configuration still is there.
    Due to the higher priority of yarn, the mapred config is not used by the
    systems:

    $ update-alternatives --display hadoop-conf
    hadoop-conf - auto mode
    link currently points to /etc/hadoop/conf.cloudera.yarn1
    /etc/hadoop/conf.cloudera.hdfs1 - priority 90
    /etc/hadoop/conf.cloudera.mapreduce1 - priority 91
    /etc/hadoop/conf.cloudera.yarn1 - priority 92
    /etc/hadoop/conf.empty - priority 10
    Current 'best' version is '/etc/hadoop/conf.cloudera.yarn1'.

    Why is the client configuration not undeployed automatically when the
    yarn1 service is stopped / the mapred1 service is started? Is it a problem
    restricted to the Ubuntu versions of CDH?

    Is there a way to undeploy the client configuration "by hand" for yarn
    from within the Cloudera Manager or do I need to write a script for it?

    kr,
    Till

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupscm-users @
categorieshadoop
postedOct 30, '12 at 3:59p
activeOct 30, '12 at 5:44p
posts3
users2
websitecloudera.com
irc#hadoop

2 users in discussion

Tmac: 2 posts Philip Langdale: 1 post

People

Translate

site design / logo © 2022 Grokbase