ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (AMBARI-20017) PixieDust - Decrease Service Check running time under 3 mins
Date Thu, 16 Feb 2017 22:00:43 GMT


Hudson commented on AMBARI-20017:

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6769 (See [])
AMBARI-20017. PixieDust - Decrease Service Check running time under 3 (dlysnichenko: [])
* (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/
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/

> PixieDust - Decrease Service Check running time under 3 mins
> ------------------------------------------------------------
>                 Key: AMBARI-20017
>                 URL:
>             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

View raw message