-
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 container upgrade --check
function
#4486
Add container upgrade --check
function
#4486
Conversation
Skipping CI for Draft Pull Request. |
Given: #4176 (comment) @cgwalters WDYT? |
@cgwalters Are we saving the current container image manifest anywhere on the system when we do the rebase? I think the approach we're looking at right now is to use the |
Yes, it's stored in the ostree commit metadata. That's how e.g. See a similar comment I made over here containers/bootc#3 |
I filed ostreedev/ostree-rs-ext#496 related to this |
f817e1d
to
5484ee2
Compare
6bbbf61
to
ba53c46
Compare
a44a070
to
61faf20
Compare
container upgrade --check
function
Applied a temporary patch in |
ostreedev/ostree-rs-ext#511 is queued, then we can change this PR to just pull in the new release |
Thanks! There's a few other tweaks I'd like to do here too before we merge. |
Closes: ostreedev#496 In coreos/rpm-ostree#4486 we were working on fixing `rpm-ostree upgrade --check` with containers. However, what we really want here is to *persist* the updated manifest (and config) that we fetch. And if we do that, we might as well just make it part of the current `prepare()` API so it happens automatically. In this change, we do so via detached commit metadata. An important thing here is that the data is then automatically lifecycle bound to the merge commit - and the merge commit always changes when we fetch a new manifest. In order to do an offline query (e.g. in rpm-ostree we want to re-synthesize a higher level summary of the queued update) add an API which allows querying a previously saved cached update. Hence a flow like this should work: - OS boots - OS updater does a background "check for updates" via calling `prepare()` - OS updater finds an update, and renders metadata to the user or orchestration system - <time passes; OS update is not downloaded - e.g. user is on metered data or whatever> - system reboots for other reasons - OS updater can re-render the fact that a queued update was found *without* touching the network - User can initiate a full fetch (e.g. including image layers) targeting *exactly* the previously prepared fetch. This makes things much more race-free; if the image was GC'd in the meantime we correctly fail.
Closes: ostreedev#496 In coreos/rpm-ostree#4486 we were working on fixing `rpm-ostree upgrade --check` with containers. However, what we really want here is to *persist* the updated manifest (and config) that we fetch. And if we do that, we might as well just make it part of the current `prepare()` API so it happens automatically. In this change, we do so via detached commit metadata. An important thing here is that the data is then automatically lifecycle bound to the merge commit - and the merge commit always changes when we fetch a new manifest. In order to do an offline query (e.g. in rpm-ostree we want to re-synthesize a higher level summary of the queued update) add an API which allows querying a previously saved cached update. Hence a flow like this should work: - OS boots - OS updater does a background "check for updates" via calling `prepare()` - OS updater finds an update, and renders metadata to the user or orchestration system - <time passes; OS update is not downloaded - e.g. user is on metered data or whatever> - system reboots for other reasons - OS updater can re-render the fact that a queued update was found *without* touching the network - User can initiate a full fetch (e.g. including image layers) targeting *exactly* the previously prepared fetch. This makes things much more race-free; if the image was GC'd in the meantime we correctly fail.
Closes: ostreedev#496 In coreos/rpm-ostree#4486 we were working on fixing `rpm-ostree upgrade --check` with containers. However, what we really want here is to *persist* the updated manifest (and config) that we fetch. And if we do that, we might as well just make it part of the current `prepare()` API so it happens automatically. In this change, we do so via detached commit metadata. An important thing here is that the data is then automatically lifecycle bound to the merge commit - and the merge commit always changes when we fetch a new manifest. Then, add this "cached update" metadata to the existing structure which has image state so it can be conveniently queried *without* re-fetching. Hence a flow like this should work: - OS boots - OS updater does a background "check for updates" via calling `prepare()` - OS updater finds an update, and renders metadata to the user or orchestration system - <time passes; OS update is not downloaded - e.g. user is on metered data or whatever> - system reboots for other reasons - OS updater can re-render the fact that a queued update was found *without* touching the network There's one notable piece that is missing to do conveniently: - User can initiate a full fetch (e.g. including image layers) targeting *exactly* the previously prepared fetch. This makes things much more race-free; if the image was GC'd in the meantime we correctly fail. But it can be done manually by e.g. using a digested pull spec temporarily.
df864bc
to
91558cd
Compare
OK, this now depends on ostreedev/ostree-rs-ext#537 Other changes:
|
91558cd
to
7ee1f4b
Compare
Actually now that I think about it, we probably don't need |
7ee1f4b
to
c8c9302
Compare
Turns out no because of course |
c8c9302
to
17f28a7
Compare
OK, rebased to pull in ostree-ext 0.12.1, so this should be good to go! |
Seems to work but I see:
is the error expected? or something I am doing wrong?
This is my system, so it's booting from my custom container build based on silverblue. I do see:
I am just not sure if the intent is to print that error and still have it print the AvailableUpdate output or maybe this should be a warning? |
f008243
to
6a2e5b7
Compare
Oh man right, the way we were doing And this is really a footgun with |
This has a few fixes, including a new update check API.
6a2e5b7
to
53711a8
Compare
Previously, OS based on native containers could not retrieve the manifest difference between the current system container image and its corresponding remote container image without performing an actual upgrade. This PR solves this issue by allowing the manifest difference to be outputted when using the `rpm-ostree upgrade --check` command. A `ManifestDiff` struct needed to be retrieved using `ostree-rs-ext`, requring several new functions in both Rust and C that were bridged through CXX Bridge. The `cached_update` object also needed to be modifed and updated with the `ManifestDiff` in order to extend compatibility with other products using rpm-ostree. However, a notable difference between how the `--upgrade --check` function works for ostree based system and a native container based system is that native containers skip over the use of `checksums`. This is because rebasing to locally stored container images (as opposed to a remote repository) does not create a valid ostree refspec. A Rust unit test was implemented to confirm that a difference between two manifests (stored locally in the rust/test folder) can be successfully retrieved. A `kola` test was also implemented to confirm that running `rpm-ostree upgrade --check` returns the correct manifest difference for a potential upgrade.
53711a8
to
c2b3110
Compare
This looks good on my manual test now too!
|
Woohoo! Thanks for fixing this! |
Fixes: #4176
Feature Implemented:
When using
sudo rpm-ostree update --check
, it will now output the manifest difference between the container image of the current system and the corresponding remote container image. More details can be found in the commit message.Sample Output:
End-to-End Test
Follow the testing setup instructions: https://coreos.github.io/rpm-ostree/HACKING/
Unit Test
$ cargo test --package rpmostree-rust --lib -- sysroot_upgrade::test_container_manifest_diff --exact --nocapture
Manual Testing Procedure:
quay.io
--bind-ro
in cosa, etc)sudo ostree admin unlock --hotfix
)sudo cp /path/to/custom/rpm-ostree /usr/bin/rpm-ostree
)sudo rpm-ostree update --check
. You should see that it outputs"No updates available. Commits are the same"
sudo rpm-ostree update --check
again. It should now show theManifestDiff