-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for --remove-installed-kernel
#4322
base: main
Are you sure you want to change the base?
Conversation
9d705f5
to
8355e69
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems sane though I wonder if a cleaner UX would be to have a dedicated override kernel-replace
command which knows to remove all the base kernel packages. The major advantage of this is that it would be the same CLI API regardless of whether it's changing kernel types or not.
Can you elaborate? "Same CLI API" as what? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate? "Same CLI API" as what?
So this is useful if you're e.g. changing from kernel to kernel-rt, where you can now do rpm-ostree install --remove-installed-kernel kernel-rt*.rpm
. But if you're changing kernel versions and not type, you still have to use rpm-ostree override replace kernel*.rpm
. So driving software have to know which path to take (by e.g. inspecting the state of the host first). I think for the MCO that's not an issue since it knows already based on the MCs what kernel type the host on. Though humans directly interacting with rpm-ostree still have to understand the difference between the two.
If we had a rpm-ostree override kernel-replace
instead, we could have it work regardless of the situation. rpm-ostree can easily know whether it's an override replace
or an override remove
+ install
.
But anyway, cool with this too, and it obviously doesn't preclude doing that down the line!
OK this PR is not critical path; I ended up with a workaround in openshift/machine-config-operator#3580 that is probably fine for now. |
Isn't this though just a specific instance of us forcing users to explicitly specify whether they're doing an override or an install? I guess there's an interesting angle here of whether actually we should think of I think if I could redesign things here honestly I feel the "override" versus "install" split we force has not carried its weight. Really of course this is just arguing that we should support This all said I do actually think bigger picture the way we in FCOS-derivatives handle And if we do that, then from the user perspective at least it's always consistently |
Right, exactly. And it'd be nice if
Can you expand on this? The split between the two has been a useful way IMO to think about package layering. Though I could imagine having only
👍 overall to the idea. I think that was considered early on when kernel-rt support was added in RHCOS but I don't remember why we went with the |
I think we lead towards getting that effect if we merge this; we can recognize the case in status where The messier thing here is then we still need to recognize which new packages are kernels...are you thinking we'd get that by having them explicit in the Mmm...hmm...I think we could expose in status which new packages were also kernel packages, then a client can render it. |
Closes: coreos#2542 Today anyone wanting to switch to a different kernel variant such as `kernel-rt` must manually pass all the *current* kernel packages to `--uninstall` (separately). It's not just very unergonomic, it also makes the calling code *operating system dependent* because as just happened when C9S added a `kernel-modules-core` package, that suddenly also needs to be specified. xref https://issues.redhat.com/browse/OCPBUGS-8113
Thought about this one some more, and I think if we agree that the "separate -rt base image" is really the way to go (and I think it probably is) then that argues against trying to special case kernel packages. Rebased 🏄 |
Hmm, not sure I follow. The proposed switch is most useful for changing kernel types. If we take that case out of the picture then |
Closes: #2542
Today anyone wanting to switch to a different kernel variant such as
kernel-rt
must manually pass all the current kernel packages to--uninstall
(separately). It's not just very unergonomic, it also makes the calling code operating system dependent because as just happened when C9S added akernel-modules-core
package, that suddenly also needs to be specified.xref https://issues.redhat.com/browse/OCPBUGS-8113