Bug 1941334 - [RFE] Cluster-api-provider-ovirt should handle auto pinning policy
Summary: [RFE] Cluster-api-provider-ovirt should handle auto pinning policy
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Cloud Compute
Version: 4.6.z
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.8.0
Assignee: Liran Rotenberg
QA Contact: Guilherme Santos
URL:
Whiteboard:
Depends On:
Blocks: 1925201
TreeView+ depends on / blocked
 
Reported: 2021-03-21 17:02 UTC by Liran Rotenberg
Modified: 2021-07-27 22:54 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Previously, when creating machine-sets one had to configure his machines with manual settings of CPU pinning, NUMA pinning and CPU topology changes to get better performance from the host. Now, a user may select a policy in the machine-set resource to do it automatically.
Clone Of:
Environment:
Last Closed: 2021-07-27 22:54:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-api-provider-ovirt pull 100 0 None open Bug 1941334: Add support for auto pinning policy 2021-03-30 06:44:21 UTC
Red Hat Product Errata RHSA-2021:2438 0 None None None 2021-07-27 22:54:57 UTC

Description Liran Rotenberg 2021-03-21 17:02:15 UTC
Current state:
cluster-api-provider has no logic for handling auto pinning policy.

What we want:
Cluster API provider should expose logic for adding a created machine having auto pinning policy by adding a field for the policy in the machine spec.

This means that when you create a machine set you can decide that all the machines will be created with an auto pinning policy.

The UI behavior to auto configure high performance VMs with the `existing` policy is not supported.

How to test?
1. Create a machine set with the auto pinning policy, for example:
```yaml
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: ovirt11-CLUSTERNAME
    machine.openshift.io/cluster-api-machine-role: worker
    machine.openshift.io/cluster-api-machine-type: worker
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: ovirt11-CLUSTERNAME
      machine.openshift.io/cluster-api-machineset: ovirt11-CLUSTERNAME-worker-1
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: ovirt11-CLUSTERNAME
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: ovirt11-CLUSTERNAME-worker-1
    spec:
      providerSpec:
        value:
          auto_pinning_policy: adjust
          apiVersion: ovirtproviderconfig.machine.openshift.io/v1beta1
          cluster_id: CLUSTERID
          cpu:
            cores: 8
            sockets: 1
            threads: 1
          credentialsSecret:
            name: ovirt-credentials
          kind: OvirtMachineProviderSpec
          memory_mb: 16000
          os_disk:
            size_gb: 31
          template_name: ovirt11-CLUSTERNAME-rhcos
          type: server
          userDataSecret:
            name: worker-user-data
```
2. Verify that 1 machine is created and added with the provided policy (disabled - do nothing; existing, will have the same cpu topology provided. In the above example 8 cores, 1 socket, 1 thread; adjust - will override the cpu topology). In both existing and adjust, the VM will be pinned to every host in the cluster, the VM should have the number of NUMA nodes as the host (with the limit of the number of CPU the VM has), those should be pinned to the host with strict mode. A fit cpu pinning string should be provided.
3. scale to 2 replicas and make sure that another machine is created and added with the same policy

Negative test suggestion:
- Try to run it on unsupported version of the engine (< 4.4.5) if possible. A warning should appear. No policy is set even if provided.

Comment 2 Liran Rotenberg 2021-06-03 06:45:41 UTC
`Existing` policy is blocked on ovirt since 4.4.7. You may still test it, in 4.4.7 or above it will cause a backend error in the engine; preventing updating/creating VM with existing policy.

Comment 3 Guilherme Santos 2021-06-14 12:06:34 UTC
Verified on:
openshift-4.8.0-0.nightly-2021-06-10-045932
ovirt-engine-4.4.7.1-0.9.el8ev.noarch

Steps:
1. create/edit the machineset resource, changing the auto_pinning_policy to adjust and the cpu topology to some arbitrary one
2. once all workers were removed, add one replica.
3. scale the replicas in 2 and 3 and so on
4. change the auto_pinning_policy to exiting

Results:
- cpu topology on the created vms automatically overridden according with hosts
- failure on engine when setting existing policy as ovirt is > 4.7:
ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-189) [] Operation Failed: [Cannot edit VM. The Auto Pinning policy Existing is currently unsupported.]

Comment 8 errata-xmlrpc 2021-07-27 22:54:36 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 (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), 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/RHSA-2021:2438


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