Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1862816

Summary:	[RFE] selecting all VMs within the affinity group for "Migrate VM" dialog doesn't auto enable the migration as it should
Product:	[oVirt] ovirt-engine	Reporter:	Sharon Gratch <sgratch>
Component:	Backend.Core	Assignee:	Sharon Gratch <sgratch>
Status:	CLOSED WONTFIX	QA Contact:	meital avital <mavital>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.4.1	CC:	ahadas, akrejcir, bugs
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	pm-rhel: ovirt-4.5? pm-rhel: planning_ack? pm-rhel: devel_ack? pm-rhel: testing_ack?
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-04-07 17:48:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	UX	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sharon Gratch 2020-08-02 19:20:08 UTC

Description of problem:
This was raised here: https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c8 
(issue 1):

If the user wants to migrate all VMs within the affinity group by selecting
them in advance, there is no need to check the "Migrate all VMs in positive
enforcing affinity with selected VMs" option.

Curenttly the user has to check this option for enabling migration since the
implementation of the api doesn't support that.
Check https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c9 and
https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c10 for discussions.

This behaviour is not user friendly from UI aspect.


Steps to Reproduce:
1. Create an affinity group with positive enforcing for VMs: vm1, vm2.
2. Choose both vm1 and vm2 and open the "migrate vm" dialog.


Actual results:
the destination hosts list is still empty and migration is disabled. Need to check the "Migrate all VMs in positive enforcing" to enable migration.


Expected results:
No need to check the "Migrate all VMs in positive enforcing" since all VMs within the affinity group are required to be migrated together anyway.

Comment 1 Arik 2021-03-21 14:57:55 UTC

Adding a new operation to the API that migrates multiple VMs just for this case doesn't seem to justify the implementation cost.
If it's still desired (not sure it is in light of the solution for bz 1772038 though) then the client side can save the user from checking the "Migrate all VMs in positive enforcing affinity with selected VMs" option in this case - moving to UX to consider.

Comment 2 Sharon Gratch 2021-03-31 11:51:38 UTC

(In reply to Arik from comment #1)
> Adding a new operation to the API that migrates multiple VMs just for this
> case doesn't seem to justify the implementation cost.
> If it's still desired (not sure it is in light of the solution for bz
> 1772038 though) then the client side can save the user from checking the
> "Migrate all VMs in positive enforcing affinity with selected VMs" option in
> this case - moving to UX to consider.

Is the solution mentioned here https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c10 feasible/easy to implement?
For checking this on web-ui side we'll need to add more queries for checking which VMs are included on the same affinity group as the others (there is no API for that) and this might be more expensive from  a performance aspect.

Comment 3 Arik 2021-03-31 21:59:57 UTC

(In reply to Sharon Gratch from comment #2)
> Is the solution mentioned here
> https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c10 feasible/easy to
> implement?

Not without introducing another endpoint in the API that migrates multiple VMs

> For checking this on web-ui side we'll need to add more queries for checking
> which VMs are included on the same affinity group as the others (there is no
> API for that) and this might be more expensive from  a performance aspect.

I see, so I'd suggest to close it

Comment 4 Sharon Gratch 2021-04-01 12:22:02 UTC

(In reply to Arik from comment #3)
> (In reply to Sharon Gratch from comment #2)
> > Is the solution mentioned here
> > https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c10 feasible/easy to
> > implement?
> 
> Not without introducing another endpoint in the API that migrates multiple
> VMs

I still don't understand why it's needed. 
We need to get the list of valid targeted hosts for the chosen listed virtual machines only for displaying the list in UI without the need to check the "Migrate all VMs in positive enforcing affinity with selected VMs" option in case all chosen VMs are already in positive affinity enforcing with each other. 
No requirement to actually migrate all those VMs. The migration can be done separately exactly as it's done today.
> 
> > For checking this on web-ui side we'll need to add more queries for checking
> > which VMs are included on the same affinity group as the others (there is no
> > API for that) and this might be more expensive from  a performance aspect.
> 
> I see, so I'd suggest to close it

OK, user experience is a bit problematic but it's not crucial (just one more redundant click) and no customer complained yet.

Comment 5 Arik 2021-04-04 17:42:54 UTC

(In reply to Sharon Gratch from comment #4)
> (In reply to Arik from comment #3)
> > (In reply to Sharon Gratch from comment #2)
> > > Is the solution mentioned here
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c10 feasible/easy to
> > > implement?
> > 
> > Not without introducing another endpoint in the API that migrates multiple
> > VMs
> 
> I still don't understand why it's needed. 
> We need to get the list of valid targeted hosts for the chosen listed
> virtual machines only for displaying the list in UI without the need to
> check the "Migrate all VMs in positive enforcing affinity with selected VMs"
> option in case all chosen VMs are already in positive affinity enforcing
> with each other. 
> No requirement to actually migrate all those VMs. The migration can be done
> separately exactly as it's done today.

If the front-end doesn't indicate the back-end that it should migrate all VMs in positive enforcing affinity with selected VMs - each migrate VM command would check if the VM can be scheduled to the target host and this would fail due to the enforcing affinity rules

Comment 6 Sharon Gratch 2021-04-07 17:48:49 UTC

(In reply to Arik from comment #5)
> (In reply to Sharon Gratch from comment #4)
> > (In reply to Arik from comment #3)
> > > (In reply to Sharon Gratch from comment #2)
> > > > Is the solution mentioned here
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c10 feasible/easy to
> > > > implement?
> > > 
> > > Not without introducing another endpoint in the API that migrates multiple
> > > VMs
> > 
> > I still don't understand why it's needed. 
> > We need to get the list of valid targeted hosts for the chosen listed
> > virtual machines only for displaying the list in UI without the need to
> > check the "Migrate all VMs in positive enforcing affinity with selected VMs"
> > option in case all chosen VMs are already in positive affinity enforcing
> > with each other. 
> > No requirement to actually migrate all those VMs. The migration can be done
> > separately exactly as it's done today.
> 
> If the front-end doesn't indicate the back-end that it should migrate all
> VMs in positive enforcing affinity with selected VMs - each migrate VM
> command would check if the VM can be scheduled to the target host and this
> would fail due to the enforcing affinity rules

OK thanks.
So based on previous comments, let's close this as WONTFIX.