Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Will it indeed be part of Sprint 10 which is now aimed for 5.9.4 v2v GA, or 5.10, without this we are actually limiting the migration plan size.
*** Bug 1592768 has been marked as a duplicate of this bug. ***
*** Bug 1613848 has been marked as a duplicate of this bug. ***
https://github.com/ManageIQ/manageiq-content/pull/418
@Fabien, any thoughts on how to test this thing?
Well, this is refactoring of the existing throttling feature that limits the number of concurrent migrations per conversion host and/or per provider. So, the test is to ensure that there is no regression.
A bug has been found and a PR has been submitted: https://github.com/ManageIQ/manageiq-content/pull/439
New commit detected on ManageIQ/manageiq-content/hammer: https://github.com/ManageIQ/manageiq-content/commit/e130743043012631bcd4f0bc26ef41a9103f5115 commit e130743043012631bcd4f0bc26ef41a9103f5115 Author: Greg McCullough <gmccullo> AuthorDate: Thu Oct 4 16:47:07 2018 -0400 Commit: Greg McCullough <gmccullo> CommitDate: Thu Oct 4 16:47:07 2018 -0400 Merge pull request #439 from fdupont-redhat/v2v_fix_admin_userid_in_throttler_launch Fix userid in transformation throttler launch (cherry picked from commit 5688461f40a7e4a0b1f507202b910e8a0ffbea5b) https://bugzilla.redhat.com/show_bug.cgi?id=1594196 content/automate/ManageIQ/Transformation/TransformationThrottler.class/__methods__/utils.rb | 2 +- spec/content/automate/ManageIQ/Transformation/TransformationThrottler.class/__methods__/utils_spec.rb | 3 +- 2 files changed, 3 insertions(+), 2 deletions(-)
Created attachment 1511660 [details] fixed_proof.png I have checked by setting concurrent migration limit with UI as well as from rail console separately, both works. When I set limit to 2 and run 3 plans with single-single vm, it just start first two and third plan waits in Pre-migration state which is what we have expected. I can also seen transformation/transformationthrottler/watch in automate.log while running through mentioned wait period. Verified on - 5.10.0.27.20181128170555_43ed8cb
What was the implementation enhancement here from the v1? The algorithm is now checking and picking the Conversion host according to the existing CPU and memory load on the host?
@daniel, nope, still not. But we moved the conversion host code to backend and there's no regression. It's not an enhancement per se.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:0212