daemon: Only remove rollback when going to do an update#3253
daemon: Only remove rollback when going to do an update#3253cgwalters wants to merge 1 commit intoopenshift:masterfrom
Conversation
A while ago, I did a patch to remove the rollback deployment from the basis of complying with security scanners - the idea was that previous deployments may have vulnerabilities and by removing the ability to boot them, we ensure that any fixed vulnerabilities can't be accessed accidentally or deliberately. More recently, we applied that patch again to try to reclaim disk space in `/boot`. However, for the latter issue we don't need to remove the rollback on boot, but only when the MCD goes to apply an OS update. It's more conservative to do things this way, and in particular doing so will avoid triggering a different bug in rpm-ostree/systemd; see https://bugzilla.redhat.com/show_bug.cgi?id=2108320
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
openshift-ci
Bot
requested review from
cheesesashimi,
kikisdeliveryservice and
sinnykumari
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
| // CleanupRollback removes the rpm-ostree rollback deployment. | ||
| // It takes up space and can cause issues when /boot contains multiple | ||
| // initramfs images: https://bugzilla.redhat.com/show_bug.cgi?id=2104619. | ||
| // We don't generally expect administrators to use this versus e.g. removing |
There was a problem hiding this comment.
we can update message here to align with removing rollback deployment during OS update.
|
Do we want to make this change or close it in favor of openshift/os#898 ? |
openshift-merge-robot
added
the
needs-rebase
|
@cgwalters: PR needs rebase. DetailsInstructions 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/test-infra repository. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
Bot
added
the
lifecycle/stale
|
@cgwalters: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
Bot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. DetailsIn 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 kubernetes/test-infra repository. |
4 participants
A while ago, I did a patch to remove the rollback deployment
from the basis of complying with security scanners - the idea
was that previous deployments may have vulnerabilities and by
removing the ability to boot them, we ensure that any fixed
vulnerabilities can't be accessed accidentally or deliberately.
More recently, we applied that patch again to try to reclaim
disk space in
/boot.However, for the latter issue we don't need to remove the rollback
on boot, but only when the MCD goes to apply an OS update.
It's more conservative to do things this way, and in particular
doing so will avoid triggering a different bug in rpm-ostree/systemd;
see https://bugzilla.redhat.com/show_bug.cgi?id=2108320