-
Feature
-
Resolution: Done
-
Critical
-
None
-
False
-
None
-
False
-
Not Selected
-
TELCOSTRAT-160 - Expeditious SNO Upgrade and Rollback To Meet Telco Far Edge KPIs
-
0% To Do, 0% In Progress, 100% Done
Epic Goal
In order to meet the short duration and multiple y-stream version upgrade requirements of far edge deployments a new Image Based Upgrade (IBU) feature is being developed for single node openshift clusters. This feature is covered under TELCOSTRAT-160.
Under the IBU feature a cluster is "upgraded" by applying cluster specific data to a generic pre-built image and pivoting to that "re-personalized" image. The process will carry forward sufficient cluster-specific attributes that the cluster is indistinguishable from the original image. During this process the cluster must re-attach to the ACM management cluster for ongoing management via policy and collection off metrics/alerts/etc.
The end-to-end upgrade process is described in this document: Image Based Upgrade (IBU) Orchestration.
The goals of this epic are to ensure and validate that clusters upgraded using IBU are able to successfully re-attach to ACM and continue operating as if they had undergone typical sequential version series of upgrades. Some of the questions to answer are:
- What is the correct method for the cluster to re-register with/re-attach to ACM?
- Copy forward the klusterlet (and other?) CR from source to target version?
- Reuse the import data from hub <cluterName>-import secret? It is likely that this procedure will occur outside the 1y expiration listed in that secret, does it need to be re-generated? If so, how?
- What are the set of cluster attributes which need to be carried forward in order to ensure that metrics/alerts/etc are correctly associated with the existing buckets?
- cluster UUID
- node/linux hostname (fqdn)
- cluster name
- other???
Why is this important?
Reliable multi-version upgrade must be achieved within a limited maintenance window and without requiring application certification on intermediate y-stream versions.
Scenarios
- Customer is running 4.12 OCP with application workload. Customer uses IBU to upgrade to 4.14 and expects the cluster to remain attached to ACM for ongoing management/LCM/observability when the upgrade completes.
Acceptance Criteria
- IBU upgraded cluster is successfully registered with ACM and all enabled addons are correctly running and reporting status (policy and observability are primary focus initially)
- IBU upgraded clusters is reporting metrics and alerts into observability and the data series are correctly correlated such that data pre and post upgrade are returned in the same series.
Dependencies (internal and external)
- ...
Previous Work (Optional):
- ...
Open questions:
- …
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>