----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27465/#review59531 -----------------------------------------------------------
Ship it! When I merge my stack refactoring patch in the near future, we can revert the code in StackServiceResponse that deals with excluded types as excluded cofig types will be automatically be removed from the service while it is being parsed. ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java <https://reviews.apache.org/r/27465/#comment100800> missing new javadoc params ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java <https://reviews.apache.org/r/27465/#comment100801> why 3 empty lines? - John Speidel On Nov. 1, 2014, 3:22 p.m., Robert Nettleton wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27465/ > ----------------------------------------------------------- > > (Updated Nov. 1, 2014, 3:22 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 > >
