Hide Forgot
Description of problem: since "Migrate" makes only sense when "Cancel Migration" is redundant and vice versa, these button could be merged to a single button with label changing based on VM(s) state in order to save space. When multiple VMs are selected, current logic may be maintained: if all selected VMs are migrate-able (up and not pinned and not in-migration), "Migrate" button is available, if not, the button is disabled. Version-Release number of selected component (if applicable): 3.3 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Malini, what do you think about dynamically changing the button/action? I can think of in multiple selection case is that if I trigger a mass migration and then some of them fail but most of them are migrating…and I still have the highlighted selection - I would like to be able to cancel the remaining ongoing migrations by a single click. Other than that functionally it's ok, I think.
moving the UX question to Einav
(In reply to Michal Skrivanek from comment #1) > Malini, what do you think about dynamically changing the button/action? > > I can think of in multiple selection case is that if I trigger a mass > migration and then some of them fail but most of them are migrating…and I > still have the highlighted selection - I would like to be able to cancel the > remaining ongoing migrations by a single click. ... or re-trigger the migration for the ones that failed. So I think that the scenario of multi-selection (in which you have both migrating and non-migrating VMs) in which we cannot guess what the user would want to do, is a good enough reason for keeping both of the 'Migrate' and 'Cancel Migration' buttons in place.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.