MCO-1026: Enhancement for bootc integration into MCO #1631

inesqyx · 2024-05-28T20:30:32Z

No description provided.

openshift-ci-robot · 2024-05-28T20:30:35Z

@inesqyx: This pull request references MCO-1026 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci · 2024-05-28T20:31:08Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

inesqyx · 2024-06-20T14:04:34Z

Tagging manually for review, apology for the spam: @cheesesashimi @yuqi-zhang @sinnykumari @mrunalp @jlebon
@cgwalters @sdodson

inesqyx · 2024-06-25T15:45:34Z

Update on Kernel Argument:
Doc: containers/bootc@a67286f
PR: containers/bootc#630

travier · 2024-06-27T15:10:55Z

https://containers.github.io/bootc/building/kernel-arguments.html

yuqi-zhang

Some suggestions inline, thanks for starting this enhancement!

My main question after reading is I'm not really sure if we're trying to describe the tech preview (and just enabling bootc in the MCO) or the overall plan for bootc via this enhancement. I think it would help me understand better if we directly state that, and have clearly defined goals around it

enhancements/machine-config/bootc_update_path.md

yuqi-zhang · 2024-06-29T00:51:58Z

enhancements/machine-config/bootc_update_path.md

+
+### Topology Considerations
+
+#### Hypershift / Hosted Control Planes


I think we will have to align with Hypershift in the future. As it stands Hypershift wouldn't utilize this codepath

Hey, Jerry! Do you by any chance know if anyone from the Hypershift team would be interested in this as well? We could include him/her/them into this conversation and review process to get better alignment in early stages.

jlebon · 2024-07-04T20:00:58Z

My main question after reading is I'm not really sure if we're trying to describe the tech preview (and just enabling bootc in the MCO) or the overall plan for bootc via this enhancement. I think it would help me understand better if we directly state that, and have clearly defined goals around it

Agreed, yeah.

I think for this enhancement, we should take a broader approach and talk more about the overall story and phases than focus on the bootc part. E.g. we could retitle it "Image-mode integration into MCO" and have phases like (this is a rough list, we'd need to agree on importance and ordering):

Phase 1: always-on on-cluster layering for updates: cluster updates always result in an on-cluster rebuild to layer MachineConfigs (i.e. no more direct writes to the host's /etc)
Phase 2: move extensions handling to on-cluster layering
Phase 3: move kernel arguments handling to on-cluster layering (via https://containers.github.io/bootc/building/kernel-arguments.html)
Phase 4: use bootc switch instead of rpm-ostree rebase

Each one of those phases has a lot of details to work through, and ironically the last phase to move from calling rpm-ostree to bootc is likely the simplest of them (but obviously opens the door to then have tighter integration with bootc, like the mentioned configmap support).

openshift-ci-robot · 2024-07-24T17:46:36Z

@inesqyx: This pull request references MCO-1026 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

openshift-ci · 2024-08-08T14:55:05Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign hasbro17 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

jlebon · 2024-08-08T14:43:57Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+### User Stories
+
+* As an OpenShift cluster administrator I would like MCO to leverage RHEL disk images to boot/update my nodes


Suggested change

* As an OpenShift cluster administrator I would like MCO to leverage RHEL disk images to boot/update my nodes

* As an OpenShift cluster administrator I would like MCO to leverage image-mode RHEL to boot/update my nodes

Disk images are only involved in the first boot of the node. After that it's container images.

jlebon · 2024-08-08T14:53:01Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will have a RHEL-bootc layer, a CoreOS layer, an OCP node layer, and day-2 configuration layers added on top built and rolled out by On Cluster Layering discussed in Phase 1. Please note here that the proposal and implementation details of the first three layers (the RHEL-bootc layer, the CoreOS layer and the OCP node layer) are explained in the Splitting the RHCOS Image into layers  enhancement, thus a non-goal for this enhancement. Some of the gaps we observed here are:
+  * "Default" MCO managed configuration moved to /usr and shipped as a container image layer: Includes all MCO specific config rendered to /usr + MachineConfigs which are rendered to /etc -> /usr/etc (to be confirmed) 
+  * Configs that involve file writing to immutable local file system directories need to be handled: The immutable CoreOS model guards the immutability of certain directories. With that being said, if we write a file (e.g. SSH key) to an immutable directory during an OS image build and use rpm-ostree to rebase onto the newly built OS image, that file will not actually be there when the node reboots. 


I think I understand what you're getting at here, but let me clarify a few things.

In a container build, there are no immutable directories. That's why you can e.g. install packages or change stuff in /usr.

/var is special. It's not immutable either but in this context, files written to it will simply be ignored when deploying to the node because nodes have their own /var that wins.

SSH keys are a big one, but it's basically any path in the MachineConfig under /var will have this issue. I think in the short/mid-term, we'll have to keep having the MCO manually write those to the nodes (though that could still be done transactionally). But ideally longer term, we can work towards moving all big use cases for this to other directories under /usr or /etc or to systemd-tmpfiles dropins instead.

https://containers.github.io/bootc/building/guidance.html#understanding-mutability and https://containers.github.io/bootc/filesystem.html cover this too

jlebon · 2024-08-08T14:58:11Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+### Phase 3: Deprecate rpm-ostree and Move Layered Image Update Path to Bootc 
+
+Upon completion of the above, the last step is to update the image rollout mechanism. In the foreseeable future, we will be expecting a dual-stream RHCOS where rpm-ostree will be gradually deprecated and transition its responsibility to bootc. Following this trend, MCO will also enable image deployment by both “rpm-ostree rebase” and “bootc switch” and, in the end, settle down on “bootc switch” for image rollout. 


What is the "dual-stream RHCOS" referring to here? I.e. that we'll have e.g. 9.x and 10.x versions? Why wouldn't they be handled the same way?

This is referring to the point at which we are supporting both rpm-ostree rebase and bootc switch as we haven't completely deprecated rpm-ostree yet. IIRC from the discussions, we never plan to ship this interim phase to customers but this will be a phase we need to cross when implementing and testing out the move to bootc. That is why the final phase of all this is to do the final move to bootc switch after OCL is GA and layered update path is made the default.

Proposal: instead of using the term "dual-stream" for this, which already has a meaning in OCP, let's use e.g. "dual support" consistently as used below?

jlebon · 2024-08-08T14:59:30Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+### Workflow Description
+
+1. The cluster administrator wants to add new configuration to the OS on each of their cluster nodes.
+2. The cluster administrator specifies base OS image pull spec & secret, base OS extension pull spec, rendered image pull spec & secret, rendered image push spec & secret and custom content through a MachineOSConfig object.


Hopefully we don't have a need for the extensions container in the future.

Also ideally there's an optimized path for the common case where the rendered image pull and push secrets are the same?

Having a common field for both secrets when they are the same comes under the OCL feature. We can discuss this while finalizing the plans and remaining work to GA OCL.

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

jlebon · 2024-08-08T18:35:53Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will have a RHEL-bootc layer, a CoreOS layer, an OCP node layer, and day-2 configuration layers added on top built and rolled out by On Cluster Layering discussed in Phase 1. Please note here that the proposal and implementation details of the first three layers (the RHEL-bootc layer, the CoreOS layer and the OCP node layer) are explained in the Splitting the RHCOS Image into layers  enhancement, thus a non-goal for this enhancement. Some of the gaps we observed here are:
+  * "Default" MCO managed configuration moved to /usr and shipped as a container image layer: Includes all MCO specific config rendered to /usr + MachineConfigs which are rendered to /etc -> /usr/etc (to be confirmed) 
+  * Configs that involve file writing to immutable local file system directories need to be handled: The immutable CoreOS model guards the immutability of certain directories. With that being said, if we write a file (e.g. SSH key) to an immutable directory during an OS image build and use rpm-ostree to rebase onto the newly built OS image, that file will not actually be there when the node reboots. 
+  * Address functionality gap between bootc and rpm-ostree: figure out a story for kernel argument changes as a container image layer/label 


There's some support for this now: https://containers.github.io/bootc/building/kernel-arguments.html

jlebon · 2024-08-08T18:39:43Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+    - A: Go bindings for bootc is not a must and, as a result, will be outside of the scope of this enhancement and will not be implemented. The main purpose of creating go bindings for rpm-ostree/bootc is to have an easier way to parse the created json and to read the status of rpm-ostree/bootc. This can be done via creating a simple wrapper function inside of the MCO. It will make sense to separate it out to a standalone helper/library in the future when the demand raises, but is a non-goal for now.
+
+* Discussion question for gaps highlighted in phase 2 
+    - Q: A problem with the current model is that configs that involve file writing to local file system directories are not respected by “rpm-ostree rebase” / “bootc switch”. For example, if we write an SSH key to “/home/core/.ssh/authorized_keys'' directory during an OS image build and use rpm-ostree to rebase onto the newly built OS image, that file will not actually be there when the node reboots. Will this be handled/considered in the future planning of RHCOS and bootc? 


This is related to my earlier comment about /var.

Fixed based on the comment earlier

jlebon · 2024-08-08T18:42:50Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+        - Everything rebootless should not be in the image, unless we have live image changes. It is better for those changes to be in writable directories on the disk. Need to keep in mind the priority order of /usr vs /etc.
+        - MCO would have to apply its own internal configs first then the MachineConfigs.
+        - [Actionable item] Get a list of files managed by the MCO to further refine this.


Avoiding reboots when possible isn't unique to OCP of course. I think ideally here we try to lower this functionality into bootc directly. See e.g. containers/bootc#76 related to this.

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

umohnani8 · 2024-09-13T13:33:51Z

@jlebon @mrunalp updated the enhancement based on reviews, PTAL

jlebon · 2024-09-17T19:22:51Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+### Phase 2: Move to Layered Update Path by Default 
+
+After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will have a RHEL-bootc layer, a CoreOS layer, an OCP node layer, and day-2 configuration layers added on top of the node image will be built and rolled out by On Cluster Layering discussed in Phase 1. Some of the gaps we observed here are:


Suggested change

After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will have a RHEL-bootc layer, a CoreOS layer, an OCP node layer, and day-2 configuration layers added on top of the node image will be built and rolled out by On Cluster Layering discussed in Phase 1. Some of the gaps we observed here are:

After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will be built by layering day-2 configuration on top of the node image and rolled out by On Cluster Layering discussed in Phase 1. Some of the gaps we observed here are:

jlebon · 2024-09-17T19:25:27Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+### Phase 2: Move to Layered Update Path by Default 
+
+After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will have a RHEL-bootc layer, a CoreOS layer, an OCP node layer, and day-2 configuration layers added on top of the node image will be built and rolled out by On Cluster Layering discussed in Phase 1. Some of the gaps we observed here are:
+  * "Default" MCO managed configuration moved to /usr and shipped as a container image layer: Includes all MCO specific config rendered to /usr + MachineConfigs which are rendered to /etc -> /usr/etc (to be confirmed) 


MachineConfigs we own can be moved to equivalent /usr paths when available (e.g. /usr/lib/systemd/system/ for systemd units). Things that don't have a /usr equivalent can just stay in /etc.

The /usr/etc bit is an implementation detail on the ostree side and should be mostly transparent to us.

updated based on this

jlebon · 2024-09-17T19:31:59Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will have a RHEL-bootc layer, a CoreOS layer, an OCP node layer, and day-2 configuration layers added on top of the node image will be built and rolled out by On Cluster Layering discussed in Phase 1. Some of the gaps we observed here are:
+  * "Default" MCO managed configuration moved to /usr and shipped as a container image layer: Includes all MCO specific config rendered to /usr + MachineConfigs which are rendered to /etc -> /usr/etc (to be confirmed) 
+  * Configs that involve file writing to immutable local file system directories need to be handled: The immutable CoreOS model guards the immutability of certain directories. With that being said, if we write a file (e.g. SSH key) to an immutable directory during an OS image build and use rpm-ostree to rebase onto the newly built OS image, that file will not actually be there when the node reboots - basically any path under */var* will be affected by this. In the interim, the MCO will continue to write these files manually onto the  nodes as it currently does. In the future, the plan is to move these files into */usr* or */etc* or use systemd-tmpfiles dropins instead.


Hmm, I don't think this quite captures the issue. Let me try:

Suggested change

* Configs that involve file writing to immutable local file system directories need to be handled: The immutable CoreOS model guards the immutability of certain directories. With that being said, if we write a file (e.g. SSH key) to an immutable directory during an OS image build and use rpm-ostree to rebase onto the newly built OS image, that file will not actually be there when the node reboots - basically any path under */var* will be affected by this. In the interim, the MCO will continue to write these files manually onto the nodes as it currently does. In the future, the plan is to move these files into */usr* or */etc* or use systemd-tmpfiles dropins instead.

* MachineConfigs that write to `/var` (this includes things like SSH keys under `/home`, which is really a symlink to `/var/home`) will need to keep being written by the MCO directly. In cases where we own the MachineConfig, we can look at whether there are `/usr` or `/etc` alternatives (or e.g. `tmpfiles.d` dropins) we can use, but in the general case and for customers, anything writing to `/var` can't be part of the layered image build since ostree by design ignores `/var` content when rolling out the update.

Does that help?

thanks, fixed

jlebon · 2024-09-17T19:35:04Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+### Phase 3: Deprecate rpm-ostree and Move Layered Image Update Path to Bootc 
+
+Upon completion of the above, the last step is to update the image rollout mechanism. In the foreseeable future, we will be expecting a dual-stream RHCOS where rpm-ostree will be gradually deprecated and transition its responsibility to bootc. Following this trend, MCO will also enable image deployment by both “rpm-ostree rebase” and “bootc switch” and, in the end, settle down on “bootc switch” for image rollout. 


Proposal: instead of using the term "dual-stream" for this, which already has a meaning in OCP, let's use e.g. "dual support" consistently as used below?

jlebon · 2024-09-17T19:37:19Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+5. The BuildController detects a build request from new MachineOSConfig/MachineConfig creation and creates a build. A new MachineOSBuild object will be created to track build progress and mark targeted rendered-MachineConfig.
+6. The built image will be pushed to the rendered image push spec specified in the MachineOSConfig object (Step 2).
+7. The MachineConfigDaemon will then drain the node and call “bootc switch” to roll the newly built image to the node, and reboot the node upon completion.
+8. If required, cluster administrator can roll back to previous image.


Worth adding details into how the admin triggers a rollback.

jlebon · 2024-09-17T19:41:07Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+  * Scenario 1: We don’t have layered update path as the default, but we start to provide rpm-ostree + bootc dual support (likely in 4.18)
+  * Scenario 2: We now have layered update path as the default and we still have rpm-ostree + bootc dual support (likely in 4.19)
+  * Scenario 3: We have completed the switch over to layered update path + bootc for image management + dnf for package management (likely in  4.20)


These sound more like milestones? I'm confused by the framing as scenarios.

These are stages we have divided the work into, so essentially milestones where we slowly add more and more support for layered update path and bootc. I have updated the wording here and called it stages instead.

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

jlebon · 2024-09-17T19:45:04Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+### Removing a deprecated feature
+
+None


If all goes well, we should be able to remove the rpm-ostree path at some point in the future. Worth calling that out I think.

Signed-off-by: Urvashi <[email protected]>

umohnani8 · 2024-09-26T14:43:10Z

@inesqyx can you please convert this from a draft to a PR. I don't seem to have access to do that.

cgwalters · 2024-10-09T14:18:04Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+On-Cluster Layering is already shipped as a tech preview version in 4.16. Currently, we are targeting 4.18 for its GA. In this phase, we are aiming that, by the time On Cluster Layering GA, it will support most day-2 configurations specified by machine config and ship the change as a container image layer, which include osImageURL specification (DONE), extensions and kernel changes (PLANNED) and file writing to mutable local file system directories (DONE). Another important GA criteria for On Cluster Layering and Phase 1 is that, currently, On Cluster Layering is only a day-2 configuration tool for Openshift, with the workflow being that you install a cluster and then opt in to it. We need to figure out an On Cluster Layering day-1 configuration story so that users can install a cluster with it.
+
+### Phase 2: Move to Layered Update Path by Default 


One thing I'm realizing here is that because on-cluster layering currently has hyper shift out of scope...we can't actually take this step fully until we switch over hyper shift to building images too, which I guess needs another enhancement?

cgwalters · 2024-10-09T14:22:03Z

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md

+
+#### Hypershift / Hosted Control Planes
+
+[TBD] We don’t anticipate any impact on Hypershift as of now. We will update this section if something comes up during the smoke tests, implementation or future planning.


openshift-bot · 2024-11-07T01:15:25Z

Inactive enhancement proposals go stale after 28d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle stale.
Stale proposals rot after an additional 7d of inactivity and eventually close.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle stale

openshift-bot · 2024-11-14T08:45:36Z

Stale enhancement proposals rot after 7d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle rotten.
Rotten proposals close after an additional 7d of inactivity.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

umohnani8 · 2024-11-19T14:44:12Z

Closing this enhancement, a new one will be opened by @LorbusChris soon.

LorbusChris · 2024-11-19T14:46:08Z

/close

openshift-ci · 2024-11-19T14:46:19Z

@LorbusChris: Closed this PR.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label May 28, 2024

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 28, 2024

inesqyx force-pushed the MCO-1026-bootc-enhancement branch from 6260522 to ad46715 Compare May 29, 2024 14:29

yuqi-zhang reviewed Jun 29, 2024

View reviewed changes

inesqyx mentioned this pull request Jul 22, 2024

Added Feature Gate for Bootc Update Path openshift/api#1969

Merged

inesqyx closed this Jul 24, 2024

inesqyx force-pushed the MCO-1026-bootc-enhancement branch from ad46715 to 57dc5f6 Compare July 24, 2024 17:39

inesqyx reopened this Jul 24, 2024

inesqyx force-pushed the MCO-1026-bootc-enhancement branch from 78cc643 to 80442b2 Compare July 24, 2024 17:47

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Outdated Show resolved Hide resolved

mrunalp reviewed Aug 2, 2024

View reviewed changes

enhancements/machine-config/alignment-with-image-mode-rhel-for-the-mco.md Show resolved Hide resolved

inesqyx force-pushed the MCO-1026-bootc-enhancement branch from 80442b2 to 4f18add Compare August 8, 2024 14:43

jlebon reviewed Aug 8, 2024

View reviewed changes

umohnani8 force-pushed the MCO-1026-bootc-enhancement branch from 4f18add to 6237ec5 Compare September 12, 2024 17:43

jlebon reviewed Sep 17, 2024

View reviewed changes

Alignment with Image Mode RHEL for the MCO

311eb0d

Signed-off-by: Urvashi <[email protected]>

umohnani8 force-pushed the MCO-1026-bootc-enhancement branch from 6237ec5 to 311eb0d Compare September 26, 2024 14:37

mrunalp marked this pull request as ready for review October 3, 2024 17:27

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 3, 2024

openshift-ci bot requested review from coverprice and dougbtv October 3, 2024 17:28

cgwalters reviewed Oct 9, 2024

View reviewed changes

coverprice removed their request for review October 9, 2024 17:45

openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 7, 2024

openshift-ci bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Nov 14, 2024

openshift-ci bot closed this Nov 19, 2024


		### Topology Considerations

		#### Hypershift / Hosted Control Planes


		### User Stories

		* As an OpenShift cluster administrator I would like MCO to leverage RHEL disk images to boot/update my nodes


		### Phase 3: Deprecate rpm-ostree and Move Layered Image Update Path to Bootc

		Upon completion of the above, the last step is to update the image rollout mechanism. In the foreseeable future, we will be expecting a dual-stream RHCOS where rpm-ostree will be gradually deprecated and transition its responsibility to bootc. Following this trend, MCO will also enable image deployment by both “rpm-ostree rebase” and “bootc switch” and, in the end, settle down on “bootc switch” for image rollout.


		### Phase 2: Move to Layered Update Path by Default

		After On Clustering GA, we will gradually deprecate the current configuration method of direct file writing to disk and move to layered update path (Phase 1) by default. At the end of this phase, OCP nodes will be configured in a full image-based way and will have a RHEL-bootc layer, a CoreOS layer, an OCP node layer, and day-2 configuration layers added on top of the node image will be built and rolled out by On Cluster Layering discussed in Phase 1. Some of the gaps we observed here are:


		On-Cluster Layering is already shipped as a tech preview version in 4.16. Currently, we are targeting 4.18 for its GA. In this phase, we are aiming that, by the time On Cluster Layering GA, it will support most day-2 configurations specified by machine config and ship the change as a container image layer, which include osImageURL specification (DONE), extensions and kernel changes (PLANNED) and file writing to mutable local file system directories (DONE). Another important GA criteria for On Cluster Layering and Phase 1 is that, currently, On Cluster Layering is only a day-2 configuration tool for Openshift, with the workflow being that you install a cluster and then opt in to it. We need to figure out an On Cluster Layering day-1 configuration story so that users can install a cluster with it.

		### Phase 2: Move to Layered Update Path by Default


		#### Hypershift / Hosted Control Planes

		[TBD] We don’t anticipate any impact on Hypershift as of now. We will update this section if something comes up during the smoke tests, implementation or future planning.

MCO-1026: Enhancement for bootc integration into MCO #1631

MCO-1026: Enhancement for bootc integration into MCO #1631

Conversation

inesqyx commented May 28, 2024

openshift-ci-robot commented May 28, 2024 • edited by openshift-ci bot Loading

openshift-ci bot commented May 28, 2024

inesqyx commented Jun 20, 2024

inesqyx commented Jun 25, 2024

travier commented Jun 27, 2024

yuqi-zhang left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jlebon commented Jul 4, 2024

openshift-ci-robot commented Jul 24, 2024 • edited by openshift-ci bot Loading

openshift-ci bot commented Aug 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

umohnani8 Sep 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

umohnani8 commented Sep 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

umohnani8 Sep 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

umohnani8 commented Sep 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openshift-bot commented Nov 7, 2024

openshift-bot commented Nov 14, 2024

umohnani8 commented Nov 19, 2024

LorbusChris commented Nov 19, 2024

openshift-ci bot commented Nov 19, 2024

openshift-ci-robot commented May 28, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Jul 24, 2024 •

edited by openshift-ci bot

Loading

umohnani8 Sep 12, 2024 •

edited

Loading

umohnani8 Sep 26, 2024 •

edited

Loading