Bug 1594810

*** Bug 1594809 has been marked as a duplicate of this bug. ***

There are quite a lot of separate RFEs contained in this report:

0) Basic functionality of creating rules, giving them name, disabling affinity and so on..

All of this should already be available in the current releases of RHV (4.2).

1) The ability to use labels in affinity groups instead of listing all VMs explicitly

This was in the original plan, but we haven't implemented it and prefer an automated tool to manage the affinity groups using Ansible or REST/SDK.

2) The ability to report affinity group conflicts

We already warn the user about conflicts we can detect at creation time. However there are conflicts that only happen when a VM that appears in multiple groups is started and we do report that conflict to the log.

3) The ability to handle "conflicts" automatically using priorities

I am open to an RFE that would give different relative weight to different soft affinity rule violations. The scheduler then tries to minimize the weight of the violations in the system (+ other constraints are taken into account too).

Hard constraints must always apply in a whole. There was probably a reason a hard constraint was created in the first place.

4) Using affinity labels/groups for hardware checks (Example Affinity Group 2)

This is one of the exact use cases we created the simple affinity labels for. Just create the label "NVIDIA" and attach it both to all VMs that require such card and to all hosts that provide such card. Already works today and does what you want.


TLDR:

All the requested features except labels in affinity groups and priorities are already implemented today to some extent. Soft affinity priorities would have to be designed and implemented.

As for connecting label/affinity group management:

Would for example an ansible based solution [1] or REST api based solution [2][3] to label / affinity group management be a better alternative? It does allow integrating with inventory management or other tools the customer might already be using. Manual management of rules with the described complexity does not sound too user friendly and would quickly turn tedious even in a small cluster.

Should labels / groups be somehow synchronized across multiple RHV instances managed by CloudForms? If yes, then this might also be something we should use the REST interface for (via SDK, Ansible or other means) and handle it in CloudForms.

The visualization part would have to be also greatly improved to make the complex rules obvious.


[1] https://docs.ansible.com/ansible/2.3/ovirt_affinity_groups_module.html and https://docs.ansible.com/ansible/2.3/ovirt_affinity_labels_module.html
[2] http://ovirt.github.io/ovirt-engine-sdk/master/services.m.html#ovirtsdk4.services.AffinityGroupsService and http://ovirt.github.io/ovirt-engine-sdk/master/services.m.html#ovirtsdk4.services.AffinityLabelsService
[3] http://ovirt.github.io/ovirt-engine-api-model/4.2/#services/affinity_groups and http://ovirt.github.io/ovirt-engine-api-model/4.2/#services/affinity_labels

(In reply to Martin Sivák from comment #3)
> 
> As for connecting label/affinity group management:
> 
> Would for example an ansible based solution [1] or REST api based solution
> [2][3] to label / affinity group management be a better alternative? It does
> allow integrating with inventory management or other tools the customer
> might already be using. Manual management of rules with the described
> complexity does not sound too user friendly and would quickly turn tedious
> even in a small cluster.
I guess this would be a good approach, but it should be somehow pre-prepared. So if the requested behavior will be covered by some ansible module, this would be sufficient. If the whole behavior is required to be written by customer himself, this would not be acceptable.


> 
> Should labels / groups be somehow synchronized across multiple RHV instances
> managed by CloudForms? If yes, then this might also be something we should
> use the REST interface for (via SDK, Ansible or other means) and handle it
> in CloudForms.
> 
> The visualization part would have to be also greatly improved to make the
> complex rules obvious.
Is this something CloudFormas already doing today? If this will be included into CFME, it will be somehow an opportunity to combine both systems a bit more.

Created attachment 1458013 [details]
Example playbook with an affinity group based on queries

> if the requested behavior will be covered by some ansible module,
> this would be sufficient

Well there are couple that could be used.

The following two let you search for VMs and hosts according to whatever criteria the query mechanism supports (see the examples):

https://docs.ansible.com/ansible/2.5/modules/ovirt_vms_facts_module.html
https://docs.ansible.com/ansible/2.5/modules/ovirt_hosts_facts_module.html

The already mentioned module https://docs.ansible.com/ansible/2.5/modules/ovirt_affinity_group_module.html then lets you create/update an affinity group and you can use the results of those queries.

See the example playbook in the attachment.

As I understand it, this RFE can be split into 3 separate RFEs:
1. Implementing priorities for soft affinity groups.
2. Allowing to use labels in affinity groups.
3. Improving the UI, so it is easier to work with affinities.

Is there anything else? If not, we can create these RFEs.

Hi, I've create the three separate RFE

* bz#01680498 - [RFE] Implement priorities for soft affinity groups
* bz#01680499 - [RFE] Allowing use of labels in affinity groups
* bz#01680503 - [RFE] Improve UI for Affinity Groups / Affinity Labels

Hi everyone! I would be happy to help out with the design of the UX/UI for this bug. @Ryan Would we be able to set up sometime to talk so I can learn more about the requirements for this?

change SLA team to virt, we're not tracking SLA separately anymore

This bz was split to bz 01680498, bz 01680499 and bz 01680503.
I see no need for this one anymore.

*** This bug has been marked as a duplicate of bug 1680503 ***