ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Speidel (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMBARI-11226) Cluster blueprint export specifies wrong host groups for components
Date Mon, 18 May 2015 20:21:59 GMT
John Speidel created AMBARI-11226:
-------------------------------------

             Summary: Cluster blueprint export specifies wrong host groups for components
                 Key: AMBARI-11226
                 URL: https://issues.apache.org/jira/browse/AMBARI-11226
             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 the
REST API:
http://host:port/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
(v6.3.4#6332)

Mime
View raw message