[jira] [Commented] (AMBARI-11226) Cluster blueprint export specifies wrong host groups for components

["Hudson (JIRA)" <ji...@apache.org>]

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

Hudson commented on AMBARI-11226:
---------------------------------

FAILURE: Integrated in Ambari-trunk-Commit #2638 (See [https://builds.apache.org/job/Ambari-trunk-Commit/2638/])
AMBARI-11226. Fix cluster blueprint export mapping of components to host groups (jspeidel: http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=6971baebb976d1b316e75a74a88c39350c79b956)
* ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ExportBlueprintRequestTest.java
* ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ExportBlueprintRequest.java


> 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:
> 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)