Created attachment 1260465 [details] one of 5 metrics collection processes failing on same collection target
Created attachment 1260466 [details] one of 5 metrics collection processes failing on same collection target
Created attachment 1260467 [details] one of 5 metrics collection processes failing on same collection target
Created attachment 1260468 [details] one of 5 metrics collection processes failing on same collection target
Created attachment 1260469 [details] one of 5 metrics collection processes failing on same collection target
Thomas, isn't bug 1429617 a duplicate of this one here?
Federica, yes the two BZ'z seem to be reporting the same timeout error for the same class.method. feel free to mark one as a duplicate of the other.
*** Bug 1429617 has been marked as a duplicate of this bug. ***
there had been a bugzilla very similar to this opened and corrected for PitneyBowes some time ago for the VMware environment. I believe that GregB and possibly Keenan were involved in the fixes.
For strictly historical captures we already split the captures into days[1]. However, when it's just picking up `last_perf_captured_on`, the calculations are taking the `start_time` and `end_time` at face value. And, `start_time` in this case is equal to `last_perf_capture_on`[2]. It can be changed to use the same date splitting and stacking as is used by the historical captures. [1] https://github.com/ManageIQ/manageiq/blob/d80866895e8f43783d55481f986f656d9589177e/app/models/metric/ci_mixin/capture.rb#L39-L48 [2] https://github.com/ManageIQ/manageiq/blob/d80866895e8f43783d55481f986f656d9589177e/app/models/metric/ci_mixin/capture.rb#L50-L53
https://github.com/ManageIQ/manageiq/pull/14332
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/557132034d200514fd07803b7bc1a74524a996c3 commit 557132034d200514fd07803b7bc1a74524a996c3 Author: Greg Blomquist <gblomqui> AuthorDate: Tue Mar 14 14:54:06 2017 -0400 Commit: Greg Blomquist <gblomqui> CommitDate: Fri Mar 17 10:53:32 2017 -0400 Split metric collections into smaller intervals When a target's `last_perf_capture_on` is far into the past, the next attempt to capture metrics for that target will result in an attempt to gather a potentially huge amount of metrics at one time. This change will break down the intervals between `last_perf_capture_on` and `today` into individual days. This is the same logic that's used when collecting gap metrics. https://bugzilla.redhat.com/show_bug.cgi?id=1429593 app/models/metric/ci_mixin/capture.rb | 35 ++++++++++++++++++----------- spec/models/metric/ci_mixin/capture_spec.rb | 10 +++++++++ 2 files changed, 32 insertions(+), 13 deletions(-)
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/f874607fdb104db3e6730473e5be59a51581229b commit f874607fdb104db3e6730473e5be59a51581229b Author: Greg Blomquist <gblomqui> AuthorDate: Fri Mar 17 11:25:24 2017 -0400 Commit: Greg Blomquist <gblomqui> CommitDate: Fri Mar 17 11:25:24 2017 -0400 Test for reversed metric dates Remove a redundant call to `map`, and add a test to make sure that the dates in metrics collection are in a properly reversed order. https://bugzilla.redhat.com/show_bug.cgi?id=1429593 app/models/metric/ci_mixin/capture.rb | 18 ++++++++++-------- spec/models/metric/ci_mixin/capture_spec.rb | 21 ++++++++++++++++++++- 2 files changed, 30 insertions(+), 9 deletions(-)
*** Bug 1428566 has been marked as a duplicate of this bug. ***
Verified on 5.8.0.13-rc2.