Details
-
Feature
-
Resolution: Won't Do
-
Major
-
None
-
None
-
None
Description
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):
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>
