[
https://issues.apache.org/jira/browse/AMBARI-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194229#comment-14194229
]
Hudson commented on AMBARI-8009:
--------------------------------
FAILURE: Integrated in Ambari-trunk-Commit #805 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/805/])
AMBARI-8009. Fixes issue where multiple configuration versions were present
when deploying cluster via a blueprint (jspeidel:
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=b583fa9f53c29a3a3640396fc8a2e58cc1a18fe8)
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java
*
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintResourceProviderTest.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/Stack.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceResponse.java
*
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ClusterResourceProviderTest.java
> Multiple config versions present after Blueprint Cluster Install
> ----------------------------------------------------------------
>
> Key: AMBARI-8009
> URL: https://issues.apache.org/jira/browse/AMBARI-8009
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 1.7.0
> Reporter: Robert Nettleton
> Assignee: Robert Nettleton
> Fix For: 1.7.0
>
> Attachments: AMBARI-8009.patch.2, AMBARI-8009_1.7.0.patch.2
>
>
> After deploying a cluster using Ambari Blueprints, some of the services
> (examples: HDFS, Yarn, Hive, etc) will report multiple service configuration
> versions after the initial startup.
> This is incorrect, since after the first cluster deployment, all
> configuration should be at Version 1 ("V1").
> The problem occurs because the Ambari Configuration engine has been modified
> to support versioning on a per-service basis in Ambari overall. The
> Blueprint processor currently uses an outdated method to publish the
> configuration changes prior to a cluster startup, and this is the root of the
> problem.
> The Blueprint deployment code in ClusterResourceProvider currently publishes
> a ClusterRequest for each configuration type encountered. Because each
> service includes multiple configuration types, the Ambari Configuration
> framework will increase version number for each type seen for a given
> service.
> The ClusterResourceProvider needs to be modified to send the ClusterRequest
> messages at the proper granularity level (one request per service, which
> includes all config types associated with that service).
> I'm currently working on a patch to resolve this, and will be submitting this
> sometime soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
