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

Bug 1862818

Summary: The "migrate VM" dialog is not supporting affinity labels as it does for affinity groups
Product: [oVirt] ovirt-engine Reporter: Sharon Gratch <sgratch>
Component: Backend.CoreAssignee: bugs <bugs>
Status: CLOSED NOTABUG QA Contact: Polina <pagranat>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4.1CC: ahadas, akrejcir, bugs
Target Milestone: ---   
Target Release: ---   
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: 2020-08-06 16:13:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sharon Gratch 2020-08-02 19:38:38 UTC 
Description of problem:
This was raised here: https://bugzilla.redhat.com/show_bug.cgi?id=1772038#c8 
(issue 2):

Calling api [1] with both parameters set 'check_vms_in_affinity_closure' and
'migration_target_of parameters' is working for affinity groups but seems ignored for affinity labels.
In case of affinity labels, the targeted hosts are always available regardless to affinity rules and even if check_vms_in_affinity_closure=false.

It was reproduced on both UI and using rest api directly.

[1]  http://ovirt.github.io/ovirt-engine-api-model/master/#services/hosts/methods/list
Comment 1 Andrej Krejcir 2020-08-03 07:50:20 UTC 
What was the exact definition of the affinity labels and groups that were used?
Comment 2 Sharon Gratch 2020-08-05 16:06:27 UTC 
(In reply to Andrej Krejcir from comment #1)
> What was the exact definition of the affinity labels and groups that were
> used?

For verifying the affinity labels use case, I removed all relevant affinity groups and just created an affinity label with the relevant VMs and then played with all other label fields. It didn't work for me with both enabling/disabling the "Implicit affinity group". 
The only scenario where it works for me was when I added the label as a VM label of an affinity group.

On all mentioned scenarios, "didn't work" means that trying to migrate few of the VMs with the affinity label was allowed without the need to enable "check_vms_in_affinity_closure". 


Am I missing something?
Comment 3 Andrej Krejcir 2020-08-06 07:58:32 UTC 
What you describe is the expected behavior.

An affinity label is just a set of VMs or hosts without any logic or behavior. If a label is not part of an affinity group, it has no effect.
The "Implicit affinity group" is a backwards compatibility feature. When it is enabled, the label behaves as a positive enforcing VM-to-host affinity group.

The parameter "check_vms_in_affinity_closure" only considers positive enforcing VM affinity. VM-to-host affinity behaves correctly without this special parameter.
Comment 4 Sharon Gratch 2020-08-06 16:13:21 UTC 
(In reply to Andrej Krejcir from comment #3)
> What you describe is the expected behavior.
> 
> An affinity label is just a set of VMs or hosts without any logic or
> behavior. If a label is not part of an affinity group, it has no effect.
> The "Implicit affinity group" is a backwards compatibility feature. When it
> is enabled, the label behaves as a positive enforcing VM-to-host affinity
> group.
> 
> The parameter "check_vms_in_affinity_closure" only considers positive
> enforcing VM affinity. VM-to-host affinity behaves correctly without this
> special parameter.

Thanks Andrej for the explanation (it's seems not documented so consider opening a doc bug, but that's a different issue). 

Anyway,in that case there is no problem and this bug can be closed.