update_agent: support rebase to OCI pullspec#1241
Conversation
f0713e1 to
1ca8a87
Compare
travier
left a comment
There was a problem hiding this comment.
Very quick look but looks good 👍🏻
jlebon
left a comment
There was a problem hiding this comment.
Let's cross-link to coreos/fedora-coreos-tracker#1823 in the commit message for the larger context.
11aa880 to
7000352
Compare
jbtrystram
left a comment
There was a problem hiding this comment.
I updated this to use ostree-remote-image so we validate the ostree signatures, as suggested in coreos/fedora-coreos-tracker#1823 (comment)
I think this is ready for review now. I will clean up and sqash commits once the design is agreed
|
OK, had some more discussion with Jlebon and travier today and there are some more things to flesh out |
|
Allright, I think this is ready for review now. I highlighted a couple of things I am unsure of. |
90c5b25 to
450550b
Compare
Switch boot images to use OCI for updates. This is a step towards bootable containers support and bootc rebase. See https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates Requires coreos/zincati#1241 See coreos/fedora-coreos-tracker#1823
add9bf7 to
c5e0459
Compare
src/rpm_ostree/cli_finalize.rs
Outdated
| // get the latest commit but that would be racy, so let's finalize the latest | ||
| // commit. | ||
| if release.is_oci { | ||
| cmd.arg("--allow-missing-checksum") |
There was a problem hiding this comment.
I think probably the cleaner thing is to have rpm-ostree accept a digested pullspec the way it accepts commit checksums and it can verify that it matches the digested pullspec that was staged. Then we can drop this.
There was a problem hiding this comment.
Yes, definitely, but that requires work in rpm-ostree, let's not block on it ?
|
Allright, I reworked this PR a bunch following the review comments, that ended up being pretty substantial changes. Overview :
TestingHere are my notes to test this out it case someone wants to experiment: Start a VM with Zincati disabled : Rebase to an OCI image in graph (recent enough to get Now import Zincati build with this PR then: Zincati should now pick up an OCI update through the OCI graph Getting zincati custom build in the COSA VMWhile we can make a custom FCOS build with an override to get our Zincati build inside, it will be erased by the content of the OCI image with a rebase, so here is how I did, after building zincati and copy the binary into In the meantime, I'll squash this and try to make commits that make sense :) |
|
Ok I just re-did the testing, OCI and regular OSTree updates works as expected. |
20f465a to
1eddd79
Compare
3519a37 to
950aa08
Compare
Add support for local OCI deployements, no longer erroring out. Use the `ostree-ext` crate to parse the ostree image reference properly. This will allow zincati to query the OCI graph and rebase to OCI images for updates. Also change the base-commit-meta object to support the OCI case where this is actually an escaped serialized OCI manifest. Use the `oci-spec` crate to deserialize it and extract the Fedora CoreOS stream info from the base OCI annotations. This works around coreos/rpm-ostree#5196
Local deployements are now unserialized with a enum being either `Checksum` or `Pullspec`. This will cue the cincinnati client to request the OCI graph in the pullspec case. [1] The custom-origin-description, if set, is passed along the rebase call, and the custom-url is updated to match the new pullspec. [2] Finally, update the polkit policy to allow Zincati to do a rebase operation. [1] Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120
In the previous implementation, we finalize what's staged without knowing because rpm-ostree deploy does not returns the staged commit. Let's query the deployments and get the checksum that matches the pullspec we have in the update payload.
When going through the update graph, Zincati searches for a node that matches the current deployement, as the starting point for the update. If the graph does not contains a matching node, zincati errors silently. While this should almost never happen, it's useful to print a warning to explain the situation if we hit that case.
in 32d76f6 we added ostree bindings to parse image references, which in turn requires glib-devel dependencies to build. Let's use the fcos-buildroot container to run the CI so we have to maintain the correct set of dependencies in one place.
950aa08 to
5b79f15
Compare
|
I just pushed because of an earlier unfortunate |
Switch boot images to use OCI for updates. This is a step towards bootable containers support and bootc rebase. See https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates Requires coreos/zincati#1241 See coreos/fedora-coreos-tracker#1823
Switch boot images to use OCI for updates. This is a step towards bootable containers support and bootc rebase. See https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates Requires coreos/zincati#1241 See coreos/fedora-coreos-tracker#1823
Switch boot images to use OCI for updates. This is a step towards bootable containers support and bootc rebase. See https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates Requires coreos/zincati#1241 See coreos/fedora-coreos-tracker#1823
Switch boot images to use OCI for updates. This is a step towards bootable containers support and bootc rebase. See https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates Requires coreos/zincati#1241 See coreos/fedora-coreos-tracker#1823
Switch boot images to use OCI for updates. This is a step towards bootable containers support and bootc rebase. See https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates Requires coreos/zincati#1241 See coreos/fedora-coreos-tracker#1823
To simplify testing for coreos/fedora-coreos-tracker#1823 This script write a Zincati status override containing a fake rpm-ostree status output to appear like it's on an OCI deployement. Zincati will look under the well-known path of /run/zincati/booted-status-override.json. The content will trigger the OCI code path in Zincati. This will later run as ExecStartPre in the zincati.service environment Just ship the migration script for now, without the zincati service changes, to allow testing. See coreos/fedora-coreos-tracker#1890 See coreos/fedora-coreos-tracker#1823 (comment) Requires zincati 0.0.30 Ref coreos/zincati#1273 Ref coreos/zincati#1241
To simplify testing for coreos/fedora-coreos-tracker#1823 This script write a Zincati status override containing a fake rpm-ostree status output to appear like it's on an OCI deployement. Zincati will look under the well-known path of /run/zincati/booted-status-override.json. The content will trigger the OCI code path in Zincati. This will later run as ExecStartPre in the zincati.service environment Just ship the migration script for now, without the zincati service changes, to allow testing. See coreos/fedora-coreos-tracker#1890 See coreos/fedora-coreos-tracker#1823 (comment) Requires zincati 0.0.30 Ref coreos/zincati#1273 Ref coreos/zincati#1241
To simplify testing for coreos/fedora-coreos-tracker#1823 This script write a Zincati status override containing a fake rpm-ostree status output to appear like it's on an OCI deployement. Zincati will look under the well-known path of /run/zincati/booted-status-override.json. The content will trigger the OCI code path in Zincati. This will later run as ExecStartPre in the zincati.service environment Just ship the migration script for now, without the zincati service changes, to allow testing. See coreos/fedora-coreos-tracker#1890 See coreos/fedora-coreos-tracker#1823 (comment) Requires zincati 0.0.30 Ref coreos/zincati#1273 Ref coreos/zincati#1241
Add a configuration knob in
updateto optionnaly use OCI pullspec instead of ostree checksums.This will default to false.
Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120