[jira] [Commented] (AMBARI-20017) PixieDust - Decrease Service Check running time under 3 mins
[ https://issues.apache.org/jira/browse/AMBARI-20017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870763#comment-15870763 ] Hudson commented on AMBARI-20017: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6769 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6769/]) AMBARI-20017. PixieDust - Decrease Service Check running time under 3 (dlysnichenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=18fc2586fa7410823b3d7a9354cf5b10be0dc2e0]) * (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6/configuration/cluster-env.xml * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/ConfigHelper.java > PixieDust - Decrease Service Check running time under 3 mins > > > Key: AMBARI-20017 > URL: https://issues.apache.org/jira/browse/AMBARI-20017 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-20017.2.patch, AMBARI-20017.3.patch, > AMBARI-20017.patch > > > Right now, Ambari has a timeout of 5-10 mins for Service Checks. > We need to ensure service checks pass in less than 3 mins for all services. > This means we need to potentially use a different configuration property if > one doesn't exist already so that QE can set it during the Ambari devdeploy > tests (in order to speed up the tests). > This will likely result in bugs in either the Ambari python scripts or the > actual services, for which we will create Jiras and assign to the appropriate > stack team. > This patch implements cluster_env/strict_service_check_type property. > Possible values are minimal (handled inside service check, runs shorter > service check action) and full (default action). If value is minimal, I also > reduce service check timeout when generating command on server in 2 times. > This way we adapt to service check timeouts that may be different for > different services. If service check takes 9 minutes of 10-minute timeout to > pass on our non-busy cluster, then it will probably take more then 10 minutes > on customers real cluster, and that is bad thing (bug) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20017) PixieDust - Decrease Service Check running time under 3 mins
[ https://issues.apache.org/jira/browse/AMBARI-20017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15868828#comment-15868828 ] Hadoop QA commented on AMBARI-20017: {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12852896/AMBARI-20017.2.patch against trunk revision . {color:green}+1 @author{color}. The patch does not contain any @author tags. {color:red}-1 tests included{color}. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color:green}+1 javac{color}. The applied patch does not increase the total number of javac compiler warnings. {color:green}+1 release audit{color}. The applied patch does not increase the total number of release audit warnings. {color:green}+1 core tests{color}. The patch passed unit tests in ambari-server. Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/10602//testReport/ Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/10602//console This message is automatically generated. > PixieDust - Decrease Service Check running time under 3 mins > > > Key: AMBARI-20017 > URL: https://issues.apache.org/jira/browse/AMBARI-20017 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-20017.2.patch, AMBARI-20017.patch > > > Right now, Ambari has a timeout of 5-10 mins for Service Checks. > We need to ensure service checks pass in less than 3 mins for all services. > This means we need to potentially use a different configuration property if > one doesn't exist already so that QE can set it during the Ambari devdeploy > tests (in order to speed up the tests). > This will likely result in bugs in either the Ambari python scripts or the > actual services, for which we will create Jiras and assign to the appropriate > stack team. > This patch implements cluster_env/strict_service_check_type property. > Possible values are minimal (handled inside service check, runs shorter > service check action) and full (default action). If value is minimal, I also > reduce service check timeout when generating command on server in 2 times. > This way we adapt to service check timeouts that may be different for > different services. If service check takes 9 minutes of 10-minute timeout to > pass on our non-busy cluster, then it will probably take more then 10 minutes > on customers real cluster, and that is bad thing (bug) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20017) PixieDust - Decrease Service Check running time under 3 mins
[ https://issues.apache.org/jira/browse/AMBARI-20017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15866816#comment-15866816 ] Hadoop QA commented on AMBARI-20017: {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12852647/AMBARI-20017.patch against trunk revision . {color:green}+1 @author{color}. The patch does not contain any @author tags. {color:red}-1 tests included{color}. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color:green}+1 javac{color}. The applied patch does not increase the total number of javac compiler warnings. {color:green}+1 release audit{color}. The applied patch does not increase the total number of release audit warnings. {color:red}-1 core tests{color}. The patch failed these unit tests in ambari-server: org.apache.ambari.server.controller.AmbariManagementControllerTest org.apache.ambari.server.controller.internal.UpgradeResourceProviderTest org.apache.ambari.server.controller.AmbariCustomCommandExecutionHelperTest org.apache.ambari.server.controller.internal.UpgradeResourceProviderHDP22Test Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/10574//testReport/ Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/10574//console This message is automatically generated. > PixieDust - Decrease Service Check running time under 3 mins > > > Key: AMBARI-20017 > URL: https://issues.apache.org/jira/browse/AMBARI-20017 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-20017.patch > > > Right now, Ambari has a timeout of 5-10 mins for Service Checks. > We need to ensure service checks pass in less than 3 mins for all services. > This means we need to potentially use a different configuration property if > one doesn't exist already so that QE can set it during the Ambari devdeploy > tests (in order to speed up the tests). > This will likely result in bugs in either the Ambari python scripts or the > actual services, for which we will create Jiras and assign to the appropriate > stack team. > This patch implements cluster_env/strict_service_check_type property. > Possible values are minimal (handled inside service check, runs shorter > service check action) and full (default action). If value is minimal, I also > reduce service check timeout when generating command on server in 2 times. > This way we adapt to service check timeouts that may be different for > different services. If service check takes 9 minutes of 10-minute timeout to > pass on our non-busy cluster, then it will probably take more then 10 minutes > on customers real cluster, and that is bad thing (bug) -- This message was sent by Atlassian JIRA (v6.3.15#6346)