-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
None
-
Bootc update path
-
13
-
False
-
None
-
False
-
Not Selected
-
To Do
-
OCPSTRAT-1188 - MCO: move image update path to bootc
-
OCPSTRAT-1188MCO: move image update path to bootc
-
67% To Do, 25% In Progress, 8% Done
-
0
-
0.000
The whole bootc integration into the MCO can be divided into three epics, each announced in an enhancement
Epic 1: Bootc Update Path
Summary: An additional image update path added to the backend of the MCO. Keeping synced with CoreOS, MCO currently utilizes a rpm-ostree-based system to engage in base image specification and layering. By adding a bootc update path, MCO, in the future, will embrace the Image Mode for RHEL and become ready to support image-based upgrade process.
Proposal:
Phase 1 Get bootc working in the MCO
- Goal:
- Discuss the feasibility of switching and identify switching risks sooner than later - enhancement
- Create a bootc update path in the MCO
- Ensure the functionality of osImageURL Update and Kernel Argument Update
- Shoot out warnings for Extension Change & Kernel Type Switch - not supported by bootc
- Implementation:
Mimic everything we have in rpm-ostree.go and creating a bootc.go Make bootc.go works with update paths in the daemonsCreate a bootc wrapper (similar to rpmostree-client-go) for bootc status reporting purposesCode merge behind FG
- People need to be aware of are:
- People working with https://github.com/openshift/machine-config-operator/tree/master/templates
- People contributing to the MCO branches but not own the changes
- Done when:
- We have an enhancement (or comparable) to describe the future bootc switching plan in the MCO, identifying dependencies, challenges, plans and blockers.
- All goals achieved
Phase 2 Get bootc working with OCL
- Goal:
- Based on the findings in spike https://issues.redhat.com/browse/MCO-1027 , theoretically no addition work is needed for wiring up bootc switching with OCL. Prove the theory with testings.
- Drawing attention to unexpected behaviours in the actual testing and address them
- Make sure support for Extension Change & Kernel Type Switch is back online with bootc TP turned on and OCL TP turned on (if not GA)
- Implementation:
- Update the image rollout command for OCL built images
- Code merge behind FG
- Done when:
- We have confidence in adapting bootc switching in OCL or concerns are raised
- All goals achieved
Phase 3 GA graduation criteria
- Goal:
- Create a bootc update path in the MCO so that the MCO will support bootable container images.
- Ensure that MCO is able to understand both rpm-ostree and bootc mutations
- Enable the user to install a cluster with bootc and transfer an old cluster to a bootc-enabled one
- Have users not notice any difference in user experiences other than that more customization and mutation options are supported
- Make bootc update path the default layered OS update path
- Dependencies:
- Openshift’s decision on whether bootc will be supported - 4.19
- bootc GA
Epic 2: Unified Update Interface @ https://issues.redhat.com/browse/MCO-1189
Summary: Currently, there are mainly three update paths built in parallel within the MCO. They separately take care of non-image updates, image updates, and updates for pools that have opted in to On Cluster Layering. As a new bootc update path will be added in with the introduction of this enhancement, MCO is looking for a better way to better manage these four update paths who manage different types of update but also shares a lot of things in common (e.g. check reconcilability). Interest and Proposals in refactoring the MCD functions and creating a unified update interface has been raised several times in previous discussions:
Epic 3: Bootc Day-2 Configuration Tools @ https://issues.redhat.com/browse/MCO-1190
Summary: Bootc has opened a door for disk image customization via configmap. Switching from rpm-ostree to bootc, MCO should not only make sure all the functionality remains but also proactively extending its support to make sure all the customization power brought in by bootc are directed to the user, allowing them to fully maximize these advantages.This will involve creating a new user-side API for fetching admin-defined configuration and pairing MCO with a bootc day-2 configuration tool for applying the customizations. Interest and Proposals in which has been raised several times in previous discussions:
- Image-Based RHEL + OCP Journey
- Admin Defined Configuration with bootable containers
- OCP Day-2 Config Roadmap
- Configmap apply for cert management