Bug 1680499 - [RFE] Allowing use of labels in affinity groups
Summary: [RFE] Allowing use of labels in affinity groups
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.2.8-2
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ovirt-4.3.6-1
: 4.3.6
Assignee: Andrej Krejcir
QA Contact: Polina
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-25 08:13 UTC by Steffen Froemer
Modified: 2020-08-03 15:33 UTC (History)
6 users (show)

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.
Clone Of:
Environment:
Last Closed: 2019-10-10 15:36:58 UTC
oVirt Team: SLA
Target Upstream Version:
Embargoed:
lsvaty: testing_plan_complete-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:3010 0 None None None 2019-10-10 15:37:11 UTC
oVirt gerrit 101706 0 master MERGED scheduler: Remove LabelFilterPolicyUnit 2021-02-01 10:28:26 UTC
oVirt gerrit 101707 0 master MERGED core: Code change in AffinityValidator and AffinityGroupDaoImpl 2021-02-01 10:28:27 UTC
oVirt gerrit 101708 0 master MERGED core: Add labels to affinity groups 2021-02-01 10:28:27 UTC
oVirt gerrit 101709 0 master MERGED webadmin: Merge classes HostsSelectionModel and VmsSelectionModel 2021-02-01 10:28:27 UTC
oVirt gerrit 101710 0 master MERGED webadmin: Enable selecting labels in affinity group dialog 2021-02-01 10:28:27 UTC
oVirt gerrit 101745 0 master MERGED webadmin: Add a checkbox to label popup to set implicit affinity group 2021-02-01 10:29:10 UTC
oVirt gerrit 102023 0 master MERGED Add services for labels in affinity groups 2021-02-01 10:28:26 UTC
oVirt gerrit 102024 0 master MERGED restapi: Add backend API resources for labels in affinity groups 2021-02-01 10:28:25 UTC
oVirt gerrit 102340 0 model_4.3 MERGED Add services for labels in affinity groups 2021-02-01 10:28:25 UTC
oVirt gerrit 102419 0 master MERGED restapi: pdate to model 4.4.5 2021-02-01 10:28:25 UTC
oVirt gerrit 103125 0 None MERGED scheduler: Remove LabelFilterPolicyUnit 2021-02-01 10:29:10 UTC
oVirt gerrit 103126 0 None MERGED core: Add labels to affinity groups 2021-02-01 10:28:26 UTC
oVirt gerrit 103127 0 None MERGED webadmin: Merge classes HostsSelectionModel and VmsSelectionModel 2021-02-01 10:28:26 UTC
oVirt gerrit 103128 0 None MERGED webadmin: Add a checkbox to label popup to set implicit affinity group 2021-02-01 10:29:10 UTC
oVirt gerrit 103129 0 None MERGED webadmin: Enable selecting labels in affinity group dialog 2021-02-01 10:28:26 UTC
oVirt gerrit 103130 0 None MERGED restapi: Add backend API resources for labels in affinity groups 2021-02-01 10:28:26 UTC

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


Note You need to log in before you can comment on or make changes to this bug.