mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mesos ReviewBot <revi...@mesos.apache.org>
Subject Re: Review Request 46307: Ignored subsequent status update in HealthStatusChange tests.
Date Sun, 17 Apr 2016 16:51:54 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46307/#review129265
-----------------------------------------------------------



Bad patch!

Reviews applied: [46307]

Failed command: ./support/apply-review.sh -n -r 46307

Error:
2016-04-17 16:51:54 URL:https://reviews.apache.org/r/46307/diff/raw/ [1446/1446] -> "46307.patch"
[1]
Total errors found: 0
Checking 1 files
Error: No line in the commit message summary may exceed 72 characters.

Full log: https://builds.apache.org/job/mesos-reviewbot/12574/console

- Mesos ReviewBot


On April 17, 2016, 3:15 p.m., haosdent huang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46307/
> -----------------------------------------------------------
> 
> (Updated April 17, 2016, 3:15 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, Greg Mann, Neil Conway, and
Timothy Chen.
> 
> 
> Bugs: MESOS-1802
>     https://issues.apache.org/jira/browse/MESOS-1802
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> We need to ignore subsequent status updates in HealthStatusChange
> tests. In our test cases, we set `consecutive_failures` to 3 in
> HealthCheck message definition. But the counter for
> `consecutiveFailures` in `mesos-health-check` would be reset to 0 after
> a success check. It is possible to continue to receive status updates
> before we stop the driver.
> 
> 
> Diffs
> -----
> 
>   src/tests/health_check_tests.cpp 1c4a554ab07731963a4a38e3ae40b0323bf317bb 
> 
> Diff: https://reviews.apache.org/r/46307/diff/
> 
> 
> Testing
> -------
> 
> # I still could not reproduce the problem in old code after repeatedly tests. So seems
no way to verify whether my assumption is correct or not.
> 
> 
> Thanks,
> 
> haosdent huang
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message