Bug 1820300

Summary: [ovirt] allow template parameters customization (mem/cpu/disk) in the machine
Product: OpenShift Container Platform Reporter: Roy Golan <rgolan>
Component: InstallerAssignee: Roy Golan <rgolan>
Installer sub component: OpenShift on RHV QA Contact: Jan Zmeskal <jzmeskal>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: urgent CC: dmoessne, jzmeskal, mrhodes, pelauter, sbonazzo
Version: 4.4   
Target Milestone: ---   
Target Release: 4.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1835795 (view as bug list) Environment:
Last Closed: 2020-07-13 17:25:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1813741, 1830001, 1835576, 1835758    
Bug Blocks: 1823808, 1823809, 1835795    

Description Roy Golan 2020-04-02 17:36:08 UTC
This bug was initially created as a copy of Bug #1813741

I am copying this bug because: 



Description of problem:

The masters/workers instance parametes should be customized using the machine pool. Today all of the parameters are set on the initial template creation, and can only be overriden by export TF_VAR_xyz, which is a bad way of exposing this capability. 

Expected results:

oVirt's machinepool object should have mem/cpu/disk size parameters, and they 
should be used to create the instances, if they are set.

Comment 1 Roy Golan 2020-04-02 17:40:31 UTC
With the change made in Bug 1813741 I'm adding the following machine config properties:

- instance type id
- vm type
- memory
- cores
- sockets
- os disk size

Comment 3 Peter Lauterbach 2020-05-01 19:46:50 UTC
This is an urgent issue, we need to use install-config, not TF env variables per OCP arch.

Comment 4 Roy Golan 2020-05-14 06:05:53 UTC
The repo has now a customization.md do document how to customize the platform.
https://github.com/openshift/installer/blob/master/docs/user/ovirt/customization.md

Jan you can start the verification by using this document or just follow the steps bellow.

Lets fully customize the masters and workers by using this in the install-config:


controlPlane:
  name: master
  platform:
    ovirt:
      cpu:
        cores: 4
        sockets: 2
      memoryMB: 10000
      osDisk:
        sizeGB: 100
      vmType: high_performance
  replicas: 3
compute:
- name: worker
  platform:
    ovirt:
      cpu:
        cores: 4
        sockets: 4
      memoryMB: 12000
      osDisk:
        sizeGB: 200
      vmType: server
  replicas: 5


* instanceTypeID can also be set, but can't be mixed with cpu or memoryMB. 
Try setting instanceTypeID: 0000000b-000b-000b-000b-00000000021f  which is the XLarge instance type with 16G mem and 4 cores


Pass criteria:
- control place disks and workers are extended beyond 16GB by request
- cpu cores and socket can be customized

Comment 7 Roy Golan 2020-05-14 13:51:27 UTC
More behaviour added is validation - the ovirt-specifics in install-config will make sure that:
 cpu.cores  > 0 
 cpu.sockets > 0
 mem  > 0
 not mixing instanceTypeID and mem or cpu
 instantceTypeID is valid UUID
 vmType is on of "server", "dekstop", "high_performance"
 osDisk.diskGB > 0

Comment 9 Jan Zmeskal 2020-05-18 14:29:04 UTC
Okay, so I tested few scenarios around this, for complete breakdown see the link in comment 8. As far as I can tell, the actual customizations do work, but I found some issues with validations. 
1. Installer allows for memoryMB with value 0
2. Installer allows for arbitrary string provided to vmType
3. When specifying disk size < 16GB, disk of 16GB is created

Point 3 isn't a big issue as long as it's documented, however points 1 and 2 are in my opinion validations not working as expected.

Tested with:
openshift-install-linux-4.5.0-0.nightly-2020-05-18-043243
rhvm-4.3.10.3-0.1.master.el7.noarch

Comment 10 Jan Zmeskal 2020-05-19 07:18:25 UTC
Since this bug is rather urgent, I'm moving to VERIFIED since the basic functionality works fine. The issues with validation are being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1837239

Comment 12 Jan Zmeskal 2020-05-19 11:32:04 UTC
*** Bug 1818577 has been marked as a duplicate of this bug. ***

Comment 14 Roy Golan 2020-05-26 09:35:42 UTC
*** Bug 1821215 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2020-07-13 17:25:20 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/RHBA-2020:2409