XML

Word

Printable

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

It is typical for cluster operators to schedule upgrades and configuration changes during maintenance windows
These maintenance windows would specify a time duration, that would be applicable at a particular date and even could be recurring, similar to Unix cronjobs
It would be good to have a mechanism to specify maintenance windows at the managed cluster/ managed cluster set level that acts as a lock for controllers that perform change.

Why is this important?

Telco RAN needs a mechanism to schedule SNO cluster platform and operator upgrades

User wants to perform a major/minor version cluster upgrade of a Single Node Openshift (SNO) cluster. As SNOs are inherently non HA, the upgrade can affect workloads.
User wants to perform OLM operators upgrades that will require downloading a large amount of artifacts. If this upgrade is performed during peak usage of the cluster this can affect workloads in environments where the bandwidth is limited.
User wants to perform OLM operator upgrade in a cluster that implicitly causes reboots of the nodes. This can affect workloads during peak usage of the cluster due to the reboots, and it’s even more troublesome if the cluster is a SNO.

CI - MUST be running successfully with tests automated
Release Technical Enablement - Provide necessary release enablement details and documents.
...

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>