The Problem 

OpenShift’s current approach to managing cluster nodes is fragmented across RHCOS, RHEL, and Windows, which slows OpenShift team velocity and degrades customer experience.  Adhering to Conway’s Law, fragmentation is seen across three different user experiences, three different technical components, and multiple different teams.  Additionally, with more teams building on top of OpenShift (Telco, CNV, etc) and enabling different cloud providers (ROKS, ARO, etc), there is an increasing need for discrete node lifecycle phases and interaction points.

Strategy Doc:

https://docs.google.com/document/d/1iqkDLQfr4nxkYdzsZE1lCp44dKSN22LkZcd7Wlzgyh4/edit#

Related: https://docs.google.com/document/d/1TzPYca_VbYvs_ElXYpXeZ_qhN5VEqtrFlCx-ai9mgA0/edit#heading=h.h5pzftiybfsn

Goals

Existing basic life cycle UX to onboard RHEL nodes  via an Ansible is painful. Need to make it not ultra painful to install and upgrade

• Add node
• Remove node
• Upgrade node software

Non Goals

We don't want to jump right in and build an operator for RHEL without understanding if its really a customer pain point. Qualitative and quantitative input from customer should guide this effort. In 4.10, we want to start a R&D around this topic and talk to as many RHEL customers as possible to assess if this effort is worth the investment or not. The Ansible playbook will be the preferred approach in 4.9 and 4.10.