Bug 1947519

Summary: Clicking the 'Start' button does not start a migration plan immediately
Product: Migration Toolkit for Virtualization Reporter: Nandini Chandra <nachandr>
Component: GeneralAssignee: Fabien Dupont <fdupont>
Status: CLOSED ERRATA QA Contact: Nandini Chandra <nachandr>
Severity: high Docs Contact: Avital Pinnick <apinnick>
Priority: medium    
Version: 2.0.0CC: amastbau, fdupont, mturley
Target Milestone: ---   
Target Release: 2.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-06-10 17:11:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nandini Chandra 2021-04-08 16:31:31 UTC
Description of problem:
-----------------------
Clicking the "start" button doesn't start a plan immediately, the button turns grey for a few seconds. The 'Start' button also turned grey for the other plans. 
The migration eventually started after clicking the 'Start' button a few times.

This didn't happen on the Beta build.


Version-Release number of selected component (if applicable):
-------------------------------------------------------------
2.0.0-7


How reproducible:
-----------------
Always


Steps to Reproduce:
-------------------
1.
2.
3.


Actual results:
---------------
Clicking the 'Start' button does not start a migration plan immediately


Expected results:
----------------
1)Clicking the 'Start' button should start a migration plan immediately 
2)When the 'Start' button is clicked for a plan, the 'Start' button for the other plans shouldn't turn grey.


Additional info:
----------------

Comment 3 Mike Turley 2021-04-08 16:55:48 UTC
Nandini, the buttons only turn grey while the Migration CR is being created, which should be quick. We can't allow the user to create another Migration CR while one is being created, because we're tracking that request in a central place and the state would get clobbered. I may be able to work around this part, though.

The wait time you're seeing after the button is re-enabled is because the controller has to catch up and pick up the Migration CR before status data is reported. However, I think this part is addressed now with https://github.com/konveyor/forklift-ui/pull/501 and https://github.com/konveyor/forklift-ui/pull/531. As soon as the CR has been created, the user will be moved to the detail page for that migration, which will then display status info once the controller has it available. If the user goes back to the plans page during that window there should be a spinner indicating that the migration is starting.

Comment 4 Mike Turley 2021-04-08 17:46:06 UTC
Also, worth noting: clicking that button multiple times does create multiple migration CRs, which is probably not great. That is a legitimate bug, we shouldn't allow the user to do that. Should also have been addressed by the PRs mentioned above though.

Comment 5 Mike Turley 2021-04-08 17:50:28 UTC
Fabien, Nandini: while the main concern of this BZ (migration appearing not to start immediately) was already addressed, I thought it was worth improving the feedback on the buttons so it is more clear what's happening. This PR stops all the other plan buttons from being greyed out, and replaces the button being clicked with a spinner while the CR is being created instead. https://github.com/konveyor/forklift-ui/pull/537

Comment 6 Fabien Dupont 2021-04-16 07:30:34 UTC
The fix should be part of build 2.0.0-17 / iib:66911.

Comment 7 Amos Mastbaum 2021-04-26 11:04:59 UTC
seems fixed, only that it opens the plan execution page, is that expected? @fdupont

Comment 8 Mike Turley 2021-04-26 14:36:00 UTC
Yes, that's expected. We made the status column respond immediately in the plans table but then realized the user will likely always want to proceed to the details page to see more information about the new migration, so we decided to take them there automatically.

Comment 9 Amos Mastbaum 2021-04-28 06:20:42 UTC
verified 
MTV 2.0.0-20 (iib:69034)

Comment 12 errata-xmlrpc 2021-06-10 17:11:46 UTC
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 (MTV 2.0.0 images), 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/RHEA-2021:2381