Epic Goal

• As a Red Hat OpenShift service, we need to warn customers installing OpenShift when there are known risks.
• As an Infrastructure Administrator installing OpenShift, if there’s a possibility that the installation has known risks, I want to be forewarned of any potential risks.

Why is this important?

• We want to prevent customers from having a bad OpenShift onboarding experience whenever possible.
• In rare circumstances, new OpenShift installations may be adversely affected due to regressions or other issues that arise until a fix is delivered.  Whenever possible and when applicable, for upgrades, we’ll create a conditional edge; however, we don’t yet have a way to prevent installs from happening.

Scenarios

Recently, on ARM64, we’ve run in the ARM64SecCompError524 issue where containers get stuck during creation — see OCPBUGS-2637. We plan to offer conditional updates to remove update recommendations from 4.10 to 4.11 on arm64, so we’ve addressed upgrade scenarios; however, we have no way to prevent installs at the moment (until a fix is delivered).

Suggested Ideas

It wouldn't be terribly hard for the installer to phone home and receive a negative installation recommendation from OSUS.  E.g. Just a nudge "This version is no longer recommended for installation, please see https://issues.redhat.com/browse/OCPBUG-1234. Do you wish to install?" w/ a --ignore-install-recommendation flags for headless installation methods where they cannot decide interactively.

Acceptance Criteria

• An OpenShift customer will be informed of known risks associated with his/her environment, along with details to the known risks, before cluster provisioning begins.
• The OpenShift customer has the option to override or ignore the known risks as part of the OpenShift installation workflow.

Previous Work (Optional):

• conditional updates PR
   

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>