I need to run out for several hours and can merge this when I get back if nobody else can do it sooner.
-John On Sun, Nov 2, 2014 at 4:14 PM, Nate Cole <[email protected]> wrote: > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27465/ > > Ship it! > > Ship It! > > > - Nate Cole > > On November 1st, 2014, 11:22 a.m. EDT, Robert Nettleton wrote: > Review request for Ambari, John Speidel and Nate Cole. > By Robert Nettleton. > > *Updated Nov. 1, 2014, 11:22 a.m.* > *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. > > 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. > > 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) > > View Diff <https://reviews.apache.org/r/27465/diff/> > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
