Bug 1680499

Summary:	[RFE] Allowing use of labels in affinity groups
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Steffen Froemer <sfroemer>
Component:	ovirt-engine	Assignee:	Andrej Krejcir <akrejcir>
Status:	CLOSED ERRATA	QA Contact:	Polina <pagranat>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.2.8-2	CC:	akrejcir, michal.skrivanek, mtessun, pelauter, rbarry, Rhev-m-bugs
Target Milestone:	ovirt-4.3.6-1	Keywords:	FutureFeature, ZStream
Target Release:	4.3.6	Flags:	lsvaty: testing_plan_complete-
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	ovirt-engine-4.3.6.6	Doc Type:	Enhancement
Doc Text:	This RFE contains 2 changes. The first is a change to the labels. They no longer have any affinity behavior, they are only sets of VMs or hosts. For compatibility, the old behavior can be restored in the UI using the checkbox 'Implicit affinity group' in the Label dialog, or in the API by setting the parameter 'has_implicit_affinity_group' when creating or editing a label. The checkbox is only visible for cluster compatibility version 4.3 or less. The second change is that labels can be added to an affinity group, to the VM or host lists. When a label is added to the VM list, the behavior is the same as if all VMs in the label were added to the affinity group. Similar behavior is for the host list.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-10-10 15:36:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	SLA	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Steffen Froemer 2019-02-25 08:13:56 UTC

1. Proposed title of this feature request
[RFE] Allowing use of labels in affinity groups

3. What is the nature and description of the request?
Same behavior as for existing labels, should exist for affinity groups. Adding tags to VMs, which are defined by affinity groups would make understanding and configuration much easier

4. Why does the customer need this? (List the business requirements here)
there is always a cause behind the definition of an affinity group. Giving them a name and made it tagable would provide easier conumption and configuration of affinity group

5. How would the customer like to achieve this? (List the functional requirements here)
- Create a affinity group
- create a tag/label for this affinity group
- assign label/tag to VM

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
- if affinity group is created and tag/label added, the tag should be available to assign to virtual machines

If the tag/label assigned to VM, the VM should now be part of this group

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
1594810

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
asap

9. Is the sales team involved in this request and do they have any additional input?
no

10. List any affected packages or components.
ovirt-engine

11. Would the customer be able to assist in testing this functionality if implemented?
sure

Comment 3 Andrej Krejcir 2019-05-14 13:33:34 UTC

I'm thinking about how to implement this, and from the description, it is not clear if it is enough for the affinity group to have only one label assigned, or it should allow multiple labels.

If an affinity group can have only one label assigned for VMs and one for hosts (it can be the same label), the change would be straightforward to implement and the affinity groups would behave the same way as currently. It would make it easier to reuse the same sets of VMs or hosts in multiple affinity groups. 

If an affinity group can have multiple labels assigned for VMs, the VM to VM affinity is tricky. It is not clear how to handle affinity between VMs with the same label and affinity between VMs with different labels.

Comment 4 Steffen Froemer 2019-06-18 13:34:05 UTC

Hi, it's difficult to say. The initial request was BZ#1594810 and using labels is only a single extraction, as I got informed, BZ#1594810 is qay to big for a single BZ.


From the examples in BZ#1594810, it would become more clear, what was the initial idea behind this RFE.

Affinity group: 1
Group name: Run VMs in Datacenter 1
Affinity: Not enforced run together
Tagnames: DC1-VMS, DC1-HOSTS
Assign the tag "DC1-VMS" to all VMs I would like to run in Datacenter 1
Assign the tag "DC1-HOSTS" to all VMs I would like to run in Datacenter 1
Result: VMs tagged with "DC1-VMS" should run on Hosts with tag "DC1-HOSTS"

Affinity group: 2
Prio: 0
Group name: Run nvidia VMs on capable hosts
Affinity: Enforced run together
Tagnames: NV-VMS, NV-HOSTS
Assign the tag "NV-VMS" to all VMs that are running calculations that need nvidia compute cards
Assign the tag "NV-HOSTS" to all Hosts that containt nvidia compute cards
Result: VMs tagged with "NV-VMS" can only be started on Hosts with tag "NV-HOSTS"

Affinity group: 3
Prio: 2
Group name: Ensure loadbalancing for application 1
Affinity: Not enforced run separate
Tagnames: APP1-VMS
Assign the tag "APP1-VMS" to all VMs that run application 1
Result: VMs tagged with "APP1-VMS" should not run on the same host, but could due to other restraints (resources, other affinity groups)

Affinity group: 4
Group name: Ensure redundance for application 2
Affinity: Enforced run separate
Tagnames: APP2-VMS
Assign the tag "APP2-VMS" to all VMs that run application 2
Result: VMs tagged with "APP2-VMS" will never run on the same host

Affinity group: 5
Prio: 5
Group name: Enable high interconnect for application 3
Affinity: Not enforced run together
Tagnames: APP3-VMS
Assign the tag "APP3-VMS" to all VMs that run application 3
Result: Result: VMs tagged with "APP3-VMS" should not run on the same host, but could due to other restraints (resources, other affinity groups)

If there are VMs tagged with both APP3-VMS and APP1-VMS then the affinity group 3 will take precedence over affinity group 5.


Does it make sense?

Comment 5 Andrej Krejcir 2019-06-18 15:48:16 UTC

Yes, it makes sense. It will be probably enough if an affinity group can have only one label for the VMs and one for the hosts.

Comment 9 Polina 2019-10-09 21:19:57 UTC

verified on the base of https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/wiki/Compute/4_0_SLA_VMS_to_Hosts_Labels. 
The old tests are run with the 'Implicit affinity group' option which sets legacy behavior for affinity labels.
The relevant new cases are - 26618, 26617, 26619, 26620, 26621, 26622, 26623, 26624, 26629, 26633, 26634, 26635.

verified on version ovirt-engine-4.3.6.6-0.1.el7.noarch

Comment 12 errata-xmlrpc 2019-10-10 15:36:58 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, 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-2019:3010