[jira] [Updated] (AMBARI-16134) Force running service checks for services before upgrade

2016-04-28 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-16134:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed
To https://git-wip-us.apache.org/repos/asf/ambari.git
   7cfcf65..1b49c6c  trunk -> trunk


> Force running service checks for services before upgrade
> 
>
> Key: AMBARI-16134
> URL: https://issues.apache.org/jira/browse/AMBARI-16134
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-16134.patch
>
>
> Just checking for service checks that were run within the last hour does not 
> seem to be a warranty of anything. For example, user could install cluster, 
> run service checks once, and then enable security/LDAP/change configuration 
> as required by some pre-upgrade check/whatever, and still have Health Check 
> passing.
> So the current idea is to check configuration change history and compare 
> config change timestamps with last time the service check for related service 
> was run.
> Also log to Ambari log timestamps of latest service checks for services, and 
> timestamps of latest service config changes (INFO level)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-16134) Force running service checks for services before upgrade

2016-04-27 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-16134:

Affects Version/s: 2.4.0

> Force running service checks for services before upgrade
> 
>
> Key: AMBARI-16134
> URL: https://issues.apache.org/jira/browse/AMBARI-16134
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-16134.patch
>
>
> Just checking for service checks that were run within the last hour does not 
> seem to be a warranty of anything. For example, user could install cluster, 
> run service checks once, and then enable security/LDAP/change configuration 
> as required by some pre-upgrade check/whatever, and still have Health Check 
> passing.
> So the current idea is to check configuration change history and compare 
> config change timestamps with last time the service check for related service 
> was run.
> Also log to Ambari log timestamps of latest service checks for services, and 
> timestamps of latest service config changes (INFO level)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-16134) Force running service checks for services before upgrade

2016-04-27 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-16134:

Status: Patch Available  (was: Open)

> Force running service checks for services before upgrade
> 
>
> Key: AMBARI-16134
> URL: https://issues.apache.org/jira/browse/AMBARI-16134
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-16134.patch
>
>
> Just checking for service checks that were run within the last hour does not 
> seem to be a warranty of anything. For example, user could install cluster, 
> run service checks once, and then enable security/LDAP/change configuration 
> as required by some pre-upgrade check/whatever, and still have Health Check 
> passing.
> So the current idea is to check configuration change history and compare 
> config change timestamps with last time the service check for related service 
> was run.
> Also log to Ambari log timestamps of latest service checks for services, and 
> timestamps of latest service config changes (INFO level)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-16134) Force running service checks for services before upgrade

2016-04-27 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-16134:

Fix Version/s: 2.4.0

> Force running service checks for services before upgrade
> 
>
> Key: AMBARI-16134
> URL: https://issues.apache.org/jira/browse/AMBARI-16134
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-16134.patch
>
>
> Just checking for service checks that were run within the last hour does not 
> seem to be a warranty of anything. For example, user could install cluster, 
> run service checks once, and then enable security/LDAP/change configuration 
> as required by some pre-upgrade check/whatever, and still have Health Check 
> passing.
> So the current idea is to check configuration change history and compare 
> config change timestamps with last time the service check for related service 
> was run.
> Also log to Ambari log timestamps of latest service checks for services, and 
> timestamps of latest service config changes (INFO level)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-16134) Force running service checks for services before upgrade

2016-04-27 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-16134:

Attachment: AMBARI-16134.patch

> Force running service checks for services before upgrade
> 
>
> Key: AMBARI-16134
> URL: https://issues.apache.org/jira/browse/AMBARI-16134
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-16134.patch
>
>
> Just checking for service checks that were run within the last hour does not 
> seem to be a warranty of anything. For example, user could install cluster, 
> run service checks once, and then enable security/LDAP/change configuration 
> as required by some pre-upgrade check/whatever, and still have Health Check 
> passing.
> So the current idea is to check configuration change history and compare 
> config change timestamps with last time the service check for related service 
> was run.
> Also log to Ambari log timestamps of latest service checks for services, and 
> timestamps of latest service config changes (INFO level)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-16134) Force running service checks for services before upgrade

2016-04-27 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-16134:

Component/s: ambari-server

> Force running service checks for services before upgrade
> 
>
> Key: AMBARI-16134
> URL: https://issues.apache.org/jira/browse/AMBARI-16134
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>
> Just checking for service checks that were run within the last hour does not 
> seem to be a warranty of anything. For example, user could install cluster, 
> run service checks once, and then enable security/LDAP/change configuration 
> as required by some pre-upgrade check/whatever, and still have Health Check 
> passing.
> So the current idea is to check configuration change history and compare 
> config change timestamps with last time the service check for related service 
> was run.
> Also log to Ambari log timestamps of latest service checks for services, and 
> timestamps of latest service config changes (INFO level)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)