ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Speidel (JIRA)" <>
Subject [jira] [Resolved] (AMBARI-11226) Cluster blueprint export specifies wrong host groups for components
Date Mon, 18 May 2015 22:03:00 GMT


John Speidel resolved AMBARI-11226.
    Resolution: Fixed

merged to trunk

> Cluster blueprint export specifies wrong host groups for components
> -------------------------------------------------------------------
>                 Key: AMBARI-11226
>                 URL:
>             Project: Ambari
>          Issue Type: Bug
>          Components: blueprints
>    Affects Versions: Ambari-2.1
>            Reporter: John Speidel
>            Assignee: John Speidel
>             Fix For: Ambari-2.1
> Steps to reproduce:
> 1. Setup a 3-node cluster (using vagrant or other option)
> 2. Using the UI, startup a cluster that includes: HDFS, Yarn/MR, Tez, Zookeeper, Ambari
Metrics. There is no need to enable HA to reproduce this problem. 
> 3. When this cluster deploys successfully, export a Blueprint from this cluster using
> api/v1/clusters/clusterone?format=blueprint
> The resulting Blueprint will include many invalid mappings. I discovered this problem
yesterday while attempting to run a "round-trip" test (start cluster, export Blueprint, re-create
cluster with exported Blueprint). I noticed that many services, including the NameNode and
any services that depend upon it, were not starting up properly.
> I will attach the Blueprint I'm seeing when I export from a running 3-node cluster with
the components listed above.
> The relationship between the components in various host groups seems to no longer match
up properly with the exported properties.
> Here are a few examples I've found:
> 1. In the attached Blueprint, the "NAMENODE" component is included in "host_group_2".
The problem is that the exported configuration refers to the NameNode being in a separate
host group:
> in "core-site": "fs.defaultFS" : "hdfs://%HOSTGROUP::host_group_1%:8020",
> in "hdfs-site: "dfs.namenode.http-address" : "%HOSTGROUP::host_group_1%:50070",
> "dfs.namenode.https-address" : "%HOSTGROUP::host_group_1%:50470",
> It's important to note that the properties above should refer to the host group that
contains the NameNode, but they actually refer to a host group "host_group_1" that does not
include a "NAMENODE".
> 2. The "SECONDARY_NAMENODE" component is included in "host_group_3", but the config refers
to a different host group:
> in "hdfs-site" : "dfs.namenode.secondary.http-address" : "%HOSTGROUP::host_group_2%:50090",
> Again, the problem is the same: the properties refer to services on a given host group,
but the services are not there.
> There are probably more examples of this in the Blueprint, but these are the most prominent.
> This causes any attempt to deploy with this Blueprint to fail, since the NameNode cannot
start with invalid configuration. Subsequently, any services that are clients of the NameNode
fail,since they attempt to connect to a service that is not deployed on the configured port.
> This will cause any attempt to "round-trip" deploy an exported Blueprint to fail.

This message was sent by Atlassian JIRA

View raw message