These are chat archives for ManageIQ/manageiq/performance

7th
Jul 2016
Oleg Barenboim
@chessbyte
Jul 07 2016 20:24
@kbrock @jrafanie what is the rationale behind marking ManageIQ/manageiq#9447 as darga/yes?
Joe Rafaniello
@jrafanie
Jul 07 2016 20:29
@chessbyte my understanding is it enables doing more performance work and possibly different logic to fix the fallout of capture_timer timing out in many environments
I'll let @kbrock speak for himself but that is why I was ok with doing it on darga
Oleg Barenboim
@chessbyte
Jul 07 2016 21:01
as long as you think it low-risk and/or well-tested
Joe Rafaniello
@jrafanie
Jul 07 2016 21:06
Well, it's a restructuring that affects collecting cap & u, so there's risk whenever we change anything there. The changes make sense. We have some test coverage although cap & u has many layers and I'm pretty sure we don't have test coverage at a more integration level. @kbrock Can you speak of why you think this is needed for darga and what we have covered in terms of unit tests/integration?
Jason Frey
@Fryguy
Jul 07 2016 21:07
Well, for one it's a straight up bug that we can't finish a perf_capture_timer call
stuff gets missed
Joe Rafaniello
@jrafanie
Jul 07 2016 21:07
@kbrock did a good job of avoiding changing :sparkles: shiny objects (bugs) he found while doing this PR
I believe his bug fixes will come later ;-)
Jason Frey
@Fryguy
Jul 07 2016 21:08
yeah, this is a base for the bug fixes
Joe Rafaniello
@jrafanie
Jul 07 2016 21:08
so, this PR was to keep as much of the same behavior
Keenan Brock
@kbrock
Jul 07 2016 21:21
@chessbyte @jrafanie sorry - it is there to address the bz of cap&u timing out
I do admit, my other agenda was making bugs in that block more evident. there have been a number of patches to b and c to fix that logic. specifically pulling back objects with no ems or that were not enabled
So since I am going to be responsible for fixing any bugs in d, I want to have a solid base
the bug is the "can't determine the queue name"
that all stems from these methods - a "bad" vm/host/storage coming back -- where "bad" means without an ems
from a performane perspective, we are getting nailed by bring back too much data and still doing N+1. so this was drastic. it explicitly showed where the data came from. so we could bring back less data - AND bring back the data we needed
Oleg Barenboim
@chessbyte
Jul 07 2016 21:39
roger - backporting
@kbrock merge conflict on app/models/metric/targets.rb when running git cherry-pick -x -m 1 1781b03 on darga branch
can you tell me how to resolve if trivial or make a PR against darga
Keenan Brock
@kbrock
Jul 07 2016 22:25
ugh
@chessbyte is that pr all set?