----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27465/#review59551 -----------------------------------------------------------
Merged to both 1.7.0 and trunk. Unit tests passed in both branches. Results : Tests run: 2207, Failures: 0, Errors: 0, Skipped: 14 ... Total run:684 Total errors:0 Total failures:0 - John Speidel On Nov. 2, 2014, 10:57 p.m., Robert Nettleton wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27465/ > ----------------------------------------------------------- > > (Updated Nov. 2, 2014, 10:57 p.m.) > > > 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 > >
