ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (AMBARI-8009) Multiple config versions present after Blueprint Cluster Install
Date Mon, 03 Nov 2014 03:31:33 GMT


Hudson commented on AMBARI-8009:

SUCCESS: Integrated in Ambari-branch-1.7.0-docker #68 (See [])
AMBARI-8009.  Fixes issue where multiple config versions are present after blueprint cluster
install (jspeidel:
* ambari-server/src/test/java/org/apache/ambari/server/controller/internal/
* ambari-server/src/main/java/org/apache/ambari/server/controller/internal/
* ambari-server/src/test/java/org/apache/ambari/server/controller/internal/
* ambari-server/src/main/java/org/apache/ambari/server/controller/internal/
* ambari-server/src/main/java/org/apache/ambari/server/controller/

> Multiple config versions present after Blueprint Cluster Install
> ----------------------------------------------------------------
>                 Key: AMBARI-8009
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message