sap_vm_provision: Add Red Hat OpenShift Virtualization as target platform

[newkit]

With this PR the sap_vm_provision role can create VMs that are tuned for running SAP worloads on Red Hat OpenShift Virtualization.

[newkit]

Could you please review @0xFelix?

[sean-freeman]

@newkit Is there justification for the code split from kubevirt_vm ?

ovirt_vm can be used against any KVM Hypervisor which has OVirt APIs enabled. The principle behind KubeVirt was the same - that it could be used for deployments to any KubeVirt instantiation, with when: statements to handle any variations of running on native KubeVirt, RH OCP, SUSE Rancher etc etc.

[newkit]

@newkit Is there justification for the code split from kubevirt_vm ?

ovirt_vm can be used against any KVM Hypervisor which has OVirt APIs enabled. The principle behind KubeVirt was the same - that it could be used for deployments to any KubeVirt instantiation, with when: statements to handle any variations of running on native KubeVirt, RH OCP, SUSE Rancher etc etc.

@sean-freeman
It's based on the code released for kubevirt_vm. I have no opportunity to test against upstream kubevirt, I cannot guarantee that it would work. I had discussion with @berndfinger about this topic. I think chances are higher, that my code works (without the ocp authentication done in the playbook) for kubevirt, but as I said, without the ability to test that I don't want to release it explicitly for kubevirt.

[sean-freeman]

@sean-freeman It's based on the code released for kubevirt_vm. I have no opportunity to test against upstream kubevirt, I cannot guarantee that it would work. I had discussion with @berndfinger about this topic. I think chances are higher, that my code works (without the ocp authentication done in the playbook) for kubevirt, but as I said, without the ability to test that I don't want to release it explicitly for kubevirt.

@newkit I do not understand the justification:

• For OVirt, the ovirt.ovirt.ovirt_vm Ansible Module and others are used. If there is anything specific to Red Hat KVM Virt., a when clause is used. The README therefore states OVirt Virtual Machine/s (e.g. Red Hat Enterprise Linux KVM)
• For KubeVirt, the kubevirt.core.kubevirt_vm Ansible Module and others are used. If there is anything specific to Red Hat OpenShift Virtualization (OCPv), then a when clause should be used. The README therefore states KubeVirt Virtual Machine/s (e.g. Red Hat OpenShift Virtualization...

This code looks 95%+ compatible with any KubeVirt Control Plane for underlying KVM Hypervisor nodes.

There is zero requirement to test the codeline with upstream KubeVirt, in the same way as the codeline has not been tested with upstream OVirt or other vendor's control plane products for OVirt (e.g. Oracle Virtualization).

[newkit]

@newkit I do not understand the justification:

* For OVirt, the `ovirt.ovirt.ovirt_vm` Ansible Module and others are used. If there is anything specific to Red Hat KVM Virt., a `when` clause is used. The README therefore states `OVirt Virtual Machine/s (e.g. Red Hat Enterprise Linux KVM)`

* For KubeVirt, the `kubevirt.core.kubevirt_vm` Ansible Module and others are used. If there is anything specific to Red Hat OpenShift Virtualization (OCPv), then a `when` clause should be used. The README therefore states `KubeVirt Virtual Machine/s (e.g. Red Hat OpenShift Virtualization...`

This code looks 95%+ compatible with any KubeVirt Control Plane for underlying KVM Hypervisor nodes.

There is zero requirement to test the codeline with upstream KubeVirt, in the same way as the codeline has not been tested with upstream OVirt or other vendor's control plane products for OVirt (e.g. Oracle Virtualization).

@dominikholler @fabiand What are your thoughts on this?

[fabiand]

Howdy.
My 2cts just because I got asked :)

The goal of this role was to provide an easy way and robust way to provision a VM on OpenShift.
A key difference between OpenSHift and KubeVirt is, that in OpenShift many more assumptions can be made about versions, features, etc.

A few issues I'd expect if this role is generalized to KubeVirt:

• Functional: The Role is referencing a RHEL 8 image containerDisk. This containerDisk can only be pulled from a subscribed cluster, and this is only OpenShift. On KubeVirt a different solution needs to be found. Node level permission issues due to mismatch between kernel and userspace i.e. apparmor issues on Debian based distros.
• Performance: Due to how KubeVirt is deployed on OpenShift, it is ensured that kernel-space and user-space match. This match is required in order to meet compatibility and performance expectations/needs. In KubeVirt there is no guarantee of what kernel the host will provide. This can lead to functional (VMs do not run) and performance issues (why do I see a 100% iops decrease).
• Testing: It's simply never been tested by @newkit on KubeVirt

If this changed towards KubeVirt, then I wonder if this role would still meet the expectations and provides the value (of bein easy, robust, and delivering performance as expected). Due to @newkit 's testing we know that this role works at least nicely with OpenShift.

Thus: Sure, as allmost (?) all software, this role could be adjusted to be agnostic.
But it has only been tested on OpenShift, and there are some know gaps if it would be generalized.

Thus we have to choose between:

1. This state: More narrow ("opinionated"), but tested, and predictable in performance and functionality.
2. KubeVirt widened: More generalized, but untested, and thus less predictable in performance and functionality.

Again, just my 2cts. HTH

[sean-freeman]

Initiative objectives and Ansible Role goals

The mission of the SAP LinuxLab Open-Source Initiative, is vendor-neutrality and creating a like-for-like outcome across multiple vendors.

In the case of the sap_vm_provision Ansible Role, the objective is to provide a near identifical input data structure and variables to provide a) Provision a VM to the target infrastructure platform b) Attach Storage to the VM c) Unlock root user, create DNS entries and /etc/hosts entries for the hosts that were provisioned.

To meet the objective, the goals are therefore to reduce variance as much as possible.

So, no @fabiand the goal was not to provision a VM on OpenShift. The goal was to create a VM on every distinct Infrastructure Platform, therein lies the challenge of scope control and what is distinct.

The example I provided before with Open Virtualization (OVirt) is accurate. The code itself is for compatibility with OVirt infrastructure platforms, therefore it would likely provision to Oracle Virtualization products with 0 code changes. Anything that is specific to RHEL KVM or legacy RHEV, uses a when: clause.

To provide an example where it went the opposite way, VMs to IBM PowerVM use the IBM PowerVC controller (akin to VMware vCenter) to perform the provisioning; this is actually an OpenStack infrastructure platform. However because the code is so specific with (a lot) of additional code bespoke to IBM PowerVM (and therein the IBM Power HMC) handled through the OpenStack API calls metadata - it is in subdir ibmpowervm_vm because there was too much variance (at an estimate, maybe 60% different than a 'normal' OpenStack provision VM)

This PR

In this PR, performing a diff shows 95%+ same code as the existing subdir for kubevirt_vm. Most of the changes are:

• development prettification (e.g. use set_fact to create __private_var key and then reference later on, instead of using the value in many places within the code)
• bug fixes not caught previously

Functional: If as you say the code contains hidden OpenShift-specific code (e.g. RHEL8 OS Image containerDisk), that will need to be resolved and when: for "switch execution logic" appended to handle the different execution paths. OVirt and KubeVirt (e.g. RH OpenShift, SUSE Rancher) are the only two platforms I do not have access to, so I cannot verify myself.

Performance: Out of scope for the Ansible Role to consider, the end-user running KubeVirt natively or another vendor implementation should be expected to be aware of such limitations you describe. It matters not to the goal of this Ansible Role to provide an equal provision to many infrastructure platforms.

Testing: As described previously, OVirt has never been tested with SLES KVM or Oracle Virtualization; nor is there any expectation to do such testing. In addition because of errors witnessed in the Ansible Module for KubeVirt which requires an end user to workaround by setting ANSIBLE_JINJA2_NATIVE=true - the Ansible Role for this infrastructure platform remains as "Experimental".

I do not seek to change this towards exclusively KubeVirt, that is not the goal. The goal is to allow any KubeVirt infrastructure platform to use this code, as you describe "agnostic" but I prefer "vendor-neutral"; therein we all benefit from the fixes a common codeline that has "switch execution logic" for the <10% of difference in the code.

You'll see many examples of this "switch execution logic" through the rest of the initiative, for example:

• community.sap_install/roles/sap_general_preconfigure/vars/RedHat_9.yml

• community.sap_install/roles/sap_general_preconfigure/vars/SLES_15.yml

• community.sap_install/roles/sap_hana_preconfigure/vars/RedHat_9.yml

• community.sap_install/roles/sap_hana_preconfigure/vars/SLES_15.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/redhat.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/suse.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/platform_cloud_aws_ec2_vs.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/platform_cloud_gcp_ce_vm.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/platform_cloud_ibmcloud_powervs.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/platform_cloud_ibmcloud_vs.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/platform_cloud_msazure_vm.yml

• community.sap_install/roles/sap_ha_pacemaker_cluster/vars/platform_hyp_ibmpower_vm.yml

[newkit]

@sean-freeman The code for redhat_ocpv has replaced the kubevirt_vm code now.

[fabiand]

@sean-freeman thanks for the extensive reply - and sorry for the PTO incurred delay. If the functional, performance, and testing relevance is as you described, then it might indeed to be tied to OCP+V.

[newkit]

I believe all issues are addressed and resolved, would you please take a look @sean-freeman ?

[rhmk]

After Reviewing the PR it LGTM. The separated code has a justification just as RHEL and SLES related code is required and no Linux generic code. That said, the role itself abstracts generic kubevirt, Rancher or OCP-V and hence gets platform independent. For the future, if SAP certifies kubevirt - if ever - it is likely they will support Rancher and Openshift as products and not an OpenSource generic one and we need to apply dedicated configs for these two. From my point a view this justifies a separate code tree if it cannot be handled with simple variables any more.

[rhmk]

LGTM