-
Epic
-
Resolution: Won't Do
-
Normal
-
None
-
None
-
Investigate the feasibility of NTO to leaverage OpenShift CoreOS Layering
-
OCPSTRAT-143Allow admins to add 3rd party and custom content to RHCOS
-
Not Selected
-
False
-
False
-
None
-
0% To Do, 0% In Progress, 100% Done
OCP/Telco Definition of Done
Epic Template descriptions and documentation.
<--- Cut-n-Paste the entire contents of this description into your new Epic --->
Epic Goal
OpenShift CoreOS Layering enhancement proposes to integrate ostree native containers or CoreOS layering via the MCO. This changes RHEL CoreOS as shipped in OpenShift to be a "base image" that can be used as in layered container builds and then booted. This will allow custom 3rd party agents delivered via RPMs installed in a container build. The MCO will roll out and monitor these custom builds the same way it does for the "pristine" CoreOS image today.
This functionality would solve the fundamental issue we have with early tuning (prior to kubelet starting) and possibly better NTO integration with HyperShift. However, this approach would pose a major challenge – the need to communicate between NTO and the TuneD processes. Investigate the feasibility of switching NTO to the CoreOS Layering model.
Why is this important?
- Early tuning in OpenShift prior to kubelet start
- Possibly solve challenges of NTO deployment in environments such as HyperShift
- Find out about the implications of this on the old MCO API
Scenarios
- ...
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- ...
Dependencies (internal and external)
- external: https://issues.redhat.com/browse/RFE-3112 : Layering: staging reboots (apply-live); MCO in-cluster builds (
MCO-375,MCO-306,MCO-307) - external: https://bugzilla.redhat.com/show_bug.cgi?id=2137299 : RFE: User-configured modification of system boot-related files
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>