[
https://issues.apache.org/jira/browse/AMBARI-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192923#comment-14192923
]
Hadoop QA commented on AMBARI-8009:
-----------------------------------
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12678643/AMBARI-8009.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/440//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/440//console
This message is automatically generated.
> 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, AMBARI-8009_1.7.0.patch
>
>
> 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)
