Feature Overview

As a OpenShift administrator, I would like a solution that allows me to upgrade from one EUS version to another with very few steps and only minimum disruption to application workloads while still allowing new application services to be deployed.

Goals

4.8

• Spike, Design, and Scope
• Begin foundational development if possible

4.9

• Foundational items delivered and back ported as necessary

4.10

• Remaining delivery artifacts complete
• Documentation and enablement complete
• Full testing complete

Requirements

Functional requirements break down into the following prioritized list:

1. Make serial upgrades safe
   1. Prevent upgrades before the core components are ready (version skewing, incompatible APIs)
   2. Prevent upgrades before operators or ready
      1. Ensure Operators have a way to express max version
      2. Ensure OLM policy is clear on what happens if max version is not specified
   3. Make back pressure items (reasons you cannot upgrade) clear to administrators along with the actions to resolve
   4. CI MUST be running with test automation
   5. Note: Forcing an upgrade is still possible
2. Make updates faster
   1. Optimize where possible to increase speed of upgrade for core components (SDN/Daemonsets)
3. Reduce the amount of workload disruption
   1. Work load disruption is not just reboots it is any disruption to workloads during the upgrade, of which a reboot is likely the worst case scenario.  This may also include things like rescheduling of workloads.
   2. We will not change the model of how components are deployed, changes to the host still require a reboot
   3. Discover and document any necessary guidelines to reduce the number of items that are developed which would cause a reboot between EUS releases where possible (4.8, 4.9).  
   4. As a stretch goal, discover if it is possible to reduce the reboots between 4.6 and 4.7 
4. Should take into consideration clusters with RHEL workers

Non-Functional Requirements

Questions to answer…

• See https://docs.google.com/document/d/17I1Wd7-R1wRxmboyv1jUFHFkqQcBTorJccdGi1ZqjQE/edit# for Q&A

Out of Scope

• It is not intended to support version skews that fall outside the upstream version skew policy
• It is not intended to eliminate all reboots
• It is not intended to skip releases at this time

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content Strategy.
• What concepts do customers need to understand to be successful in [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or Release Note)?