-
Feature
-
Resolution: Unresolved
-
Undefined
-
None
-
ACM 2.13.5, acm 2.15.z
-
None
-
False
-
-
False
-
Not Selected
Feature Overview
...
Goals
This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature
- Customer wants to make use of RHACM for the OCP upgrades
- They want to orchestrate the OCP Upgrade flow using Ansible.
- They want to fine grain the tasks and maintain control over the tasks to be performed in the limited time window.
- Single policy template for all their clusters (100+).
- The requirement is to achieve all the above task with the single touch upgrade for the OCP clusters (4.14 EUS to 4.18 EUS) in the disconnected environment.
Detailing of the Upgrade steps
| Procedure | Ansible Run | Steps | Policy/Ansible |
| Pre Requisite | 1 | Pre Requisite as per MOP | Ansible |
| Mirroring of Platform and OLM Operators | |||
| 2 | Configuring cluster to use the resources generated by oc-mirror--Applying ICSP Applying catalog source with different name |
Policy | |
| Backup ETCD Database | 3 | Backup ETCD Database | Ansible |
| Migrating from ELK to Loki/Vector stack | Migrating from ELK to Loki/Vector stack | ||
| 4 | 1-Migrating the log collector from Fluentd to Vector | Ansible | |
| 4 | 2-Migrating the default log store from Elasticsearch to Loki | ||
| 4 | 3-Disconnect Elasticsearch and Kibana CRs from ClusterLogging | ||
| 4 | 4-Switch ClusterLogging to LokiStack | ||
| Creating MachineConfigPool groups for the cluster | Manual | ||
| Pausing a MachineHealthCheck resource | 5 | Ansible | |
| Healthcheck | 6 | Ansible | |
| Procedure (From 4.14.43 to 4.15.52 to 4.16.42) | |||
| 7 | Pausing all worker nodes using mcp | Policy/ansible | |
| 7 | Backup ETCD database | Ansible | |
| 7 | Acknowledging the control plan only or y-stream upgrade | Policy | |
| 7 | Complete the administrative acknowledgment to start the cluster update and Verify the updates | NA | |
| 7 | Upgrade the cluster from 4.14.43 to 4.15.52 | Policy | |
| 7 | OLM Operators upgrade to 4.15 | Policy | |
| 7 | OLM Operator checks after upgrade (status and version specific check) | Policy |
Requirements
This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.
| Requirement | Notes | isMvp? |
|---|---|---|
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. |
YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. |
YES |
(Optional) Use Cases
This Section:
- Main success scenarios - high-level user stories
- Alternate flow/scenarios - high-level user stories
- ...
Questions to answer
- ...
Out of Scope
- …
Background, and strategic fit
This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?
Assumptions
- ...
Customer Considerations
- ...
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 a 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)?
