change required minimum disk size from 120GB to 100GB

[miabbott]

Which section(s) is the issue in?

https://docs.openshift.com/container-platform/4.8/installing/installing_bare_metal/installing-bare-metal.html#minimum-resource-requirements_installing-bare-metal
https://docs.openshift.com/container-platform/4.8/installing/installing_ibm_z/installing-ibm-z-kvm.html#minimum-resource-requirements_installing-ibm-z-kvm

https://github.com/openshift/openshift-docs/blob/main/modules/installation-requirements-user-infra.adoc
https://github.com/openshift/openshift-docs/blob/main/modules/installation-requirements-user-infra-ibm-z-kvm.adoc

What needs fixing?

The minimum required disk size is stated as 120GB but this is too large. Anecdotal evidence has shown that 100GB is a more appropriate minimum.

Discussion

This change was spurred on by work being done for IBM Cloud. The RHCOS disk image for IBM Cloud currently has the virtual size hard coded to 100GB, as recommended by the IBM Cloud documentation. See the original PR for the change for context - coreos/coreos-assembler#2041 (comment)

However, the folks working on IBM Cloud support for all of OCP noted that our documentation states that 120GB is the minimum.

An issue was opened upstream in the Fedora CoreOS tracker requesting that the disk size was increased. Since FCOS is the upstream to RHCOS, this change would affect both projects.

coreos/fedora-coreos-tracker#931

During the discussion on that ticket (and in internal Slack discussions), the best path forward appeared to be an update to the OCP docs. This is because the IBM Cloud does not support resizing the disk in the cloud and it is suspected that is not possible for the installer to resize the disk before the upload to the cloud.

Alternatively, if the broad minimum cannot be changed, it has been suggested that we change the docs to note that the 100GB minimum would apply to IBM Cloud.

This ticket has been opened to allow for discussion on the proposed change to our documented minimums and any implications that may have.

[miabbott]

cc: @ashcrow @nstielau @derekwaynecarr @relyt0925 @jeffnowicki

[cgwalters]

To me a bottom line here is "what do our default e2e tests require". Hmm actually do we have any e2e tests that cover IBM Cloud VPC installs? I'm not seeing them offhand in release controller.

[cgwalters]

related openshift/installer#5169

[nstielau]

From background conversations, it seems like this original decision was partly based on the fact that iops and storage scale together in public clouds.

I think we should

• Decrease the storage GB requirement to 100GB
• Add a new column for iops, and designate 300 as the minimum for all instance types.
• Specify a footnote for the iops column: "OpenShift and Kubernetes are sensitive to disk performance, and faster storage is recommended, particularly for etcd on the control plane nodes which require a 10ms p99 fsync duration. Note that on many cloud storage size and iops scale together, so you may need to over-allocate storage volume to obtain sufficient performance."

[cgwalters]

Decrease the storage GB requirement to 100GB

👍

iops and storage scale together in public clouds.

I think Azure is strictest about that, but they're pretty decoupled in AWS for example.

But completely agree about IOPS being quite important here versus disk size.

[cuppett]

Agreed here. 100GB fine as a minimum (assuming our IOPS and latency requirements are met). 120GB was what we increased it to in our initial releases on AWS with gp2 to satisfy our IOPS needs to pass the e2e CI suites reliably.

[relyt0925]

I agree as well!!!!!! (From IBM Cloud side)

[derekwaynecarr]

Agree.

[nstielau]

@relyt0925 Please consider these approval comments as approval for this change and to let you run within the OCP requirements. I'll work on getting this drafted and merged, but that shouldn't stop you from doing what you need.

[holgwolf]

Comment from Z and LinuxONE side, I agree in lower the boundary and appreciate, but we need the same change for all Z and LinuxONE configurations including zVM setup.