-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
BU Product Work
-
False
-
-
False
-
100% To Do, 0% In Progress, 0% Done
-
7
-
0
Feature Overview (aka. Goal Summary)
Delivering the HyperShift Operator to ROSA/HCP currently involves:
- Manually tagging GitHub commit
- Get the reference for that commit Konflux build
- Use tooling to Generate a changelog
- Use tooling to put up App-Interface merge requests for changing integration to the new Konflux build
- Seek manual approval of the Merge Requests
- Trigger QE regression tests in Integration
This feature is about getting each build delivered completely automatically to Integration while increasing the observability of the process and automatically triggering the regression testing
Goals (aka. expected user outcomes)
- Each merged commit makes its way to integration without manual intervention
- InScope visibility
- Accurate changelog tracking
- Adopt automated soaking and roll out
- Reduce release duty engineering/qe toil
Requirements (aka. Acceptance Criteria):
- Agreement with ServiceDelivery on release cadence to staging and production
- Easy to find changelogs between environments
- No negative impact on SLOs
- No additional tool maintenance
Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed. Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.
| Deployment considerations | List applicable specific needs (N/A = not applicable) |
| Self-managed, managed, or both | Managed ROSA/HCP |
| Classic (standalone cluster) | No |
| Hosted control planes | Yes |
| Multi node, Compact (three node), or Single node (SNO), or all | Not applicable |
| Connected / Restricted Network | Not applicable |
| Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | Not applicable |
| Operator compatibility | Not applicable |
| Backport needed (list applicable versions) | Not applicable |
| UI need (e.g. OpenShift Console, dynamic plugin, OCM) | Not applicable |
| Other (please specify) |
Questions to Answer (Optional):
- How often is too often?
- What should be the soak time?
- Which slack channels should be notified of the roll out progression
Out of Scope
Be able to have a different progression to production for features vs fixes. Feature gates should be able to do away with this concern soon
Background
Progressive delivery was not tackled during GA. The manual process has seen increasing automation and it is now time to make delivering the HyperShift Operator make the most of the facilities that exist in Service Delivery and Konflux.
Customer Considerations
Allow for quicker turnaround for fixes.
Documentation Considerations
- HyperShift SOP describing the pipeline with troubleshooting steps
Interoperability Considerations
It impacts ROSA/HCP. It will probably inform the outcome of ARO automation as well
