1. Proposed title of this feature request [RFE] Improve UI for Affinity Groups / Affinity Labels 3. What is the nature and description of the request? Currently there are two separate UI segments to configure - "affinity groups" where it is possible to configure a list of VMs and/or a list of HVs with rules if they should run together or not. - "affinity labels" where on specific use case (enforced affinity VM to HV) can be configured 4. Why does the customer need this? (List the business requirements here) To easer management and better understanding this UI has to be improved. 5. How would the customer like to achieve this? (List the functional requirements here) A combined or single interface to create Affinity Group only. * Rule creation with an optional custom name for the rule. * Rules can contain affinities or anti-affinities, either enforced or not enforced * Rules only contain tag names/group names * It should be possible to deactivate rules A Label should be created only on Host level or via Affinity Group (see bz#01680498). 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. 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 Hosts are located 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 contain 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 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
Deferring for now, since it's unlikely that any major UI change will make it into 4 3 with the current schedule
@Ryan I can at least get started on an updated design for how a user interacts with affinity groups and labels. I think it would also be worthwhile to see how we might surface affinity groups/labels more prominently when a user goes through the process of creating a new VM.
Hey Laura - I'd love to find some time to meet with you about this and the other one
Laura, Ryan if possible, I would like to join as well. Maybe it's also worth to invite my customer, as the intention to change come from him.
Please take into account the following inconsistency related to the affinity UI: We now could add affinity group for either the VM or the Host exactly the same way while creating the VM or Host. And I was expecting that Affinity Groups and Affinity Labels will also be seen in tabs of each entity also the same way. But it is not. On VM there are both tabs 'Affinity Groups' and 'Affinity Labels', on the Host there is only 'Affinity Labels'. I'm talking about the attached windows host_tab.png and VM_tab.png
Created attachment 1595103 [details] host screen shot
Created attachment 1595104 [details] VM screenshot
Also please note, there is an inconsistency in deleting of the Affinity Label in UI. It could not be deleted from Compute/Virtual Machines/Entity (VM or Host)/Affinity Label tab. Only by Edit window. It is not intuitive. The Affinity Group, on the contrary, could be deleted from both places.
While adding a new affinity group conflicting with another existing group the user gets an error window talking about VM Ids which looks hard readable. It would be more user-friendly to have VM names in this window. example in attached AffinityOperationCanceled.png. Error while executing action: Affinity Group collision detected in unified affinity group of VMs: 2fc8b45a-0c4a-4d3b-ab4a-1aa04bedafad,20cf3692-3c57-4a31-8cbd-ff2e7e1fbf2d,1f90184f-9694-4ddd-8339-b8ce1d64cd09,54574224-bc48-4f57-bac9-25f79808f0c5 and negative affinity group: A with VMs: 2fc8b45a-0c4a-4d3b-ab4a-1aa04bedafad,1f90184f-9694-4ddd-8339-b8ce1d64cd09
Created attachment 1600953 [details] screenshot
Created attachment 1622708 [details] screenshot EditAffinityLabel
A small note for'Edit Affinity Label window'. It is inconvenient that while choosing an additional VM by clicking on '+', the opened list is not pop up. To see the VMs for choice, the user must go to the main window scrolling (attached EditAffinityLabel_VmsList.png) first
change SLA team to virt, we're not tracking SLA separately anymore
*** Bug 1594810 has been marked as a duplicate of this bug. ***
(In reply to Steffen Froemer from comment #0) > 5. How would the customer like to achieve this? (List the functional > requirements here) > A combined or single interface to create Affinity Group only. > > * Rule creation with an optional custom name for the rule. > * Rules can contain affinities or anti-affinities, either enforced or not > enforced > * Rules only contain tag names/group names > * It should be possible to deactivate rules > > > A Label should be created only on Host level or via Affinity Group (see > bz#01680498). > > > 6. For each functional requirement listed, specify how Red Hat and the > customer can test to confirm the requirement is successfully implemented. > 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 Hosts are located 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 contain 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 I see that we now have all that. The only exception I see is having Affinity Labels serving as the tags in those examples. The things Polina commented on above are more bugs than RFE and should be handled separately.