Re: Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/48553/#review137060 --- Ship it! In the context of this issue the fix looks good. As the config it self is an excluded config it shoudl be ok to ignore that it is not associated with any service type. - Sumit Mohanty On June 10, 2016, 7:09 p.m., Robert Nettleton wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/48553/ > --- > > (Updated June 10, 2016, 7:09 p.m.) > > > Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Robert > Levas, Sandor Magyari, and Sumit Mohanty. > > > Bugs: AMBARI-17151 > https://issues.apache.org/jira/browse/AMBARI-17151 > > > Repository: ambari > > > Description > --- > > This patch resolves AMBARI-17151. > > As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing > during the configuration resolution phase. This particular failure will only > occur when a user has removed a set of services from the Ambari Stack > definitions after the ambari-server install, and a component in the specified > Blueprint for this deployment includes an "excluded" configuration type > reference to a removed service. > > In the past, the Blueprint processor operated under the assumption that the > stacks were static in nature. This patch allows the Blueprint configuration > processor to be more lenient when changes like this are made to the stacks in > a custom environment. > > This patch implements the following: > > 1. Updates the "addExcludedConfigProperties" method in the > BlueprintConfigurationProcessor to detect the case where an excluded > configuration type exists for a service that the stack definitions do not > include. Currently, this can only occur if custom changes (removal of > service(s)) are made to the stack definitions. > 2. When this exceptional case is encountered, the > BlueprintConfigurationProcessor will now log a message, indicating that no > matching service is found for the given excluded configuration type, and that > this is likely caused by a change in the stack definitions. The logged > message will probably also be useful in the future to debug errors in new > stack definitions. > 3. Implements a unit test to verify this change. > > > Diffs > - > > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java > de70a2c > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java > 9ec0a09 > > Diff: https://reviews.apache.org/r/48553/diff/ > > > Testing > --- > > 1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster > will work properly, even after manually removing the "STORM" service from all > stacks in the ambari-server install. Since Metrics has an excluded > configuration reference to Storm, this verifies the original problem. With > this patch applied, the cluster deploys properly, without the configuration > exception mentioned in the associated bug JIRA. > > 2. Ran "mvn clean test" with my patch applied to trunk: > > > " > Results : > > Tests in error: > AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice > pro... > KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » > Provision G... > KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » > Provision G... > KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » > Provision G... > StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at > '/... > StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari > Stack ... > StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari > Sta... > > Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34 > " > > Note: There were 7 errors during this run, but I verified that these > failures occur on trunk without my patch applied, so these failures are not > caused by this current patch. > > 3. Ran "mvn clean test" with this morning's latest trunk src, with this patch > applied, and the full suite passed: > > "Results : > > Tests run: 4477, Failures: 0, Errors: 0, Skipped: 34" > > > Thanks, > > Robert Nettleton > >
Re: Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/48553/#review137057 --- Ship it! Ship It! - Robert Levas On June 10, 2016, 3:09 p.m., Robert Nettleton wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/48553/ > --- > > (Updated June 10, 2016, 3:09 p.m.) > > > Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Robert > Levas, Sandor Magyari, and Sumit Mohanty. > > > Bugs: AMBARI-17151 > https://issues.apache.org/jira/browse/AMBARI-17151 > > > Repository: ambari > > > Description > --- > > This patch resolves AMBARI-17151. > > As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing > during the configuration resolution phase. This particular failure will only > occur when a user has removed a set of services from the Ambari Stack > definitions after the ambari-server install, and a component in the specified > Blueprint for this deployment includes an "excluded" configuration type > reference to a removed service. > > In the past, the Blueprint processor operated under the assumption that the > stacks were static in nature. This patch allows the Blueprint configuration > processor to be more lenient when changes like this are made to the stacks in > a custom environment. > > This patch implements the following: > > 1. Updates the "addExcludedConfigProperties" method in the > BlueprintConfigurationProcessor to detect the case where an excluded > configuration type exists for a service that the stack definitions do not > include. Currently, this can only occur if custom changes (removal of > service(s)) are made to the stack definitions. > 2. When this exceptional case is encountered, the > BlueprintConfigurationProcessor will now log a message, indicating that no > matching service is found for the given excluded configuration type, and that > this is likely caused by a change in the stack definitions. The logged > message will probably also be useful in the future to debug errors in new > stack definitions. > 3. Implements a unit test to verify this change. > > > Diffs > - > > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java > de70a2c > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java > 9ec0a09 > > Diff: https://reviews.apache.org/r/48553/diff/ > > > Testing > --- > > 1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster > will work properly, even after manually removing the "STORM" service from all > stacks in the ambari-server install. Since Metrics has an excluded > configuration reference to Storm, this verifies the original problem. With > this patch applied, the cluster deploys properly, without the configuration > exception mentioned in the associated bug JIRA. > > 2. Ran "mvn clean test" with my patch applied to trunk: > > > " > Results : > > Tests in error: > AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice > pro... > KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » > Provision G... > KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » > Provision G... > KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » > Provision G... > StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at > '/... > StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari > Stack ... > StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari > Sta... > > Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34 > " > > Note: There were 7 errors during this run, but I verified that these > failures occur on trunk without my patch applied, so these failures are not > caused by this current patch. > > 3. Ran "mvn clean test" with this morning's latest trunk src, with this patch > applied, and the full suite passed: > > "Results : > > Tests run: 4477, Failures: 0, Errors: 0, Skipped: 34" > > > Thanks, > > Robert Nettleton > >
Re: Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/48553/ --- (Updated June 10, 2016, 3:39 p.m.) Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Sandor Magyari, and Sumit Mohanty. Bugs: AMBARI-17151 https://issues.apache.org/jira/browse/AMBARI-17151 Repository: ambari Description --- This patch resolves AMBARI-17151. As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing during the configuration resolution phase. This particular failure will only occur when a user has removed a set of services from the Ambari Stack definitions after the ambari-server install, and a component in the specified Blueprint for this deployment includes an "excluded" configuration type reference to a removed service. In the past, the Blueprint processor operated under the assumption that the stacks were static in nature. This patch allows the Blueprint configuration processor to be more lenient when changes like this are made to the stacks in a custom environment. This patch implements the following: 1. Updates the "addExcludedConfigProperties" method in the BlueprintConfigurationProcessor to detect the case where an excluded configuration type exists for a service that the stack definitions do not include. Currently, this can only occur if custom changes (removal of service(s)) are made to the stack definitions. 2. When this exceptional case is encountered, the BlueprintConfigurationProcessor will now log a message, indicating that no matching service is found for the given excluded configuration type, and that this is likely caused by a change in the stack definitions. The logged message will probably also be useful in the future to debug errors in new stack definitions. 3. Implements a unit test to verify this change. Diffs - ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java de70a2c ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java 9ec0a09 Diff: https://reviews.apache.org/r/48553/diff/ Testing (updated) --- 1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster will work properly, even after manually removing the "STORM" service from all stacks in the ambari-server install. Since Metrics has an excluded configuration reference to Storm, this verifies the original problem. With this patch applied, the cluster deploys properly, without the configuration exception mentioned in the associated bug JIRA. 2. Ran "mvn clean test" with my patch applied to trunk: " Results : Tests in error: AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice pro... KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision G... KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision G... KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision G... StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at '/... StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari Stack ... StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari Sta... Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34 " Note: There were 7 errors during this run, but I verified that these failures occur on trunk without my patch applied, so these failures are not caused by this current patch. 3. Ran "mvn clean test" with this morning's latest trunk src, with this patch applied, and the full suite passed: "Results : Tests run: 4477, Failures: 0, Errors: 0, Skipped: 34" Thanks, Robert Nettleton
Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/48553/ --- Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Sandor Magyari, and Sumit Mohanty. Bugs: AMBARI-17151 https://issues.apache.org/jira/browse/AMBARI-17151 Repository: ambari Description --- This patch resolves AMBARI-17151. As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing during the configuration resolution phase. This particular failure will only occur when a user has removed a set of services from the Ambari Stack definitions after the ambari-server install, and a component in the specified Blueprint for this deployment includes an "excluded" configuration type reference to a removed service. In the past, the Blueprint processor operated under the assumption that the stacks were static in nature. This patch allows the Blueprint configuration processor to be more lenient when changes like this are made to the stacks in a custom environment. This patch implements the following: 1. Updates the "addExcludedConfigProperties" method in the BlueprintConfigurationProcessor to detect the case where an excluded configuration type exists for a service that the stack definitions do not include. Currently, this can only occur if custom changes (removal of service(s)) are made to the stack definitions. 2. When this exceptional case is encountered, the BlueprintConfigurationProcessor will now log a message, indicating that no matching service is found for the given excluded configuration type, and that this is likely caused by a change in the stack definitions. The logged message will probably also be useful in the future to debug errors in new stack definitions. 3. Implements a unit test to verify this change. Diffs - ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java de70a2c ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java 9ec0a09 Diff: https://reviews.apache.org/r/48553/diff/ Testing --- 1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster will work properly, even after manually removing the "STORM" service from all stacks in the ambari-server install. Since Metrics has an excluded configuration reference to Storm, this verifies the original problem. With this patch applied, the cluster deploys properly, without the configuration exception mentioned in the associated bug JIRA. 2. Ran "mvn clean test" with my patch applied to trunk: " Results : Tests in error: AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice pro... KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision G... KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision G... KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision G... StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at '/... StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari Stack ... StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari Sta... Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34 " Note: There were 7 errors during this run, but I verified that these failures occur on trunk without my patch applied, so these failures are not caused by this current patch. Thanks, Robert Nettleton
