ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Nettleton" <rnettle...@hortonworks.com>
Subject Review Request 27465: Adds support for proper configuration versioning with Blueprints
Date Sat, 01 Nov 2014 15:22:35 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27465/
-----------------------------------------------------------

Review request for Ambari, John Speidel and Nate Cole.


Bugs: AMBARI-8009
    https://issues.apache.org/jira/browse/AMBARI-8009


Repository: ambari


Description
-------

This patch implements a fix for AMBARI-8009.

The configuration versions displayed in the Ambari UI
  are incorrect when a cluster is deployed with Blueprints.
  After an initial deployment, multiple configuration versions
  are displayed for various services (HDFS, Yarn, Hive, etc).  This
  is incorrect, since each service should be a the initial "V1"
  version after a cluster startup.

This patch implements a fix to the ClusterResourceProvider's
  handling of cluster creation via a Blueprint.  In this case,
  a ClusterRequest object is now created on per-service basis,
  as opposed to the previous implementation that created a
  ClusterRequest on a per-configuration type basis.  The new
  approach combines ClusterRequests for a given service, such
  that all config types associated with the service are
  included in the ClusterRequest.

The "cluster-env" config element is handled as a special case,
  and is added to the list of ClusterRequests prior to
  publishing the configuration.
  
  
This patch also adds a small modification to the StackServiceResponse
 API, in order to support obtaining the set of "excluded" 
 configuration types.  This is necessary in order to 
 properly group the configuration types by service, since 
 some services reference config types that are not 
 directly associated with the service. An example 
 of this usage would be that Falcon's service metadata
 references "oozie-site".  The "oozie-site" config type
 must be processed with the Oozie Service, and not with
 Falcon, in order to properly organize the ClusterRequest
 instances for configuration updates on a per-service
 basic. 

This patch also updates several unit test cases in
  ClusterResourceProviderTest that involve cluster
  creation via Blueprints.


Diffs
-----

  ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceResponse.java
9c986b1 
  ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java
8dd06ec 
  ambari-server/src/main/java/org/apache/ambari/server/controller/internal/Stack.java 3ccae43

  ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintResourceProviderTest.java
3b3ec5f 
  ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ClusterResourceProviderTest.java
319d3a9 

Diff: https://reviews.apache.org/r/27465/diff/


Testing
-------

1. Ran the ambari-server unit tests with my patch applied to trunk and 1.7.0.  The unit tests
all pass in either case.
2. Manually verified the fix against a trunk-based install.
3. Manually verified the fix against a 1.7.0-based install.  


Thanks,

Robert Nettleton


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message