[
https://issues.apache.org/jira/browse/AMBARI-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Nettleton updated AMBARI-8009:
-------------------------------------
Attachment: AMBARI-8009.patch
AMBARI-8009_1.7.0.patch
> 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)
