Add an API+CLI to inject metadata for bootable OSTree commits #2296
Conversation
32b3ec2 to
8556e52
Compare
|
OK yeah we need to drop Travis, it's been dead for a while due to the Docker rate limiting. I may look at GH actions for that. |
|
@cgwalters: Overrode contexts on behalf of cgwalters: continuous-integration/travis-ci/pr 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 kubernetes/test-infra repository. |
| gboolean | ||
| ostree_commit_metadata_for_bootable (GFile *root, GVariantDict *dict, GCancellable *cancellable, GError **error) | ||
| { | ||
| g_autoptr(GFile) modules = g_file_resolve_relative_path (root, "usr/lib/modules"); |
There was a problem hiding this comment.
This looks like pretty much the same logic of https://github.com/ostreedev/ostree/blob/v2020.8/src/libostree/ostree-sysroot-deploy.c#L1054
There was a problem hiding this comment.
Yeah...hard to share logic because using the libostree API abstraction means the content to be committed may not be realized as physical files, and we need to support that here. (For example, this API allows reading from an archive repository directly, and while it's usually better to have a checkout, it can be very convenient to do some operations on an archive repo directly)
Whereas the sysroot logic always operates on a bare repo with real files.
That logic is also trying to handle the legacy cases, which this one is explicitly not supporting.
I was doing some rpm-ostree work and I wanted to compare two OSTree commits to see if the kernel has changed. I think this should be a lot more natural. Add `ostree commit --bootable` which calls into a new generic library API `ostree_commit_metadata_for_bootable()` that discovers the kernel version and injects it as an `ostree.linux` metadata key. And for extra clarity, add an `ostree.bootable` key. It's interesting because the "core" OSTree layer is all about generic files, but this is adding special APIs around bootable OSTree commits (as opposed to e.g. flatpak as well as things like rpm-ostree's pkgcache refs). Eventually, I'd like to ensure everyone is using this and hard require this metadata key for the `ostree admin deploy` flow - mainly to prevent accidents.
Yeah, I was reading clap-rs/clap#552 recently. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, jlebon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
In general, is ostree supposed to handle multiple (inactive) kernel images in a commit? |
No; we should only have one. OSTree is all about a mechanism to transactionally swap between versioned bootable filesystem trees. We don't have code to install or switch to alternative kernels inside a single ostree commit. Instead, OS builders can ship multiple OSTree commits, and switch between them client or server side. These ostree commits will share storage via hardlinks. This is very relevant to OpenShift where we want to expose the ability to switch between the mainline |
|
Or another way to say this is - handling multiple kernel versions is no different than handling multiple versions of any other (userspace) component of the ostree payload, e.g. systemd - those are distinct commits which one can generate client or server side; it wouldn't make much sense to offer a way to switch systemd versions inside a single commit. |
|
@cgwalters thanks for the explanation, it clarified all my doubts! |
I was doing some rpm-ostree work and I wanted to compare two
OSTree commits to see if the kernel has changed. I think
this should be a lot more natural.
Add
ostree commit --bootablewhich calls into a new genericlibrary API
ostree_commit_metadata_for_bootable()thatdiscovers the kernel version and injects it as an
ostree.linuxmetadata key. And for extra clarity, add an
ostree.bootablekey.
It's interesting because the "core" OSTree layer is all about
generic files, but this is adding special APIs around bootable
OSTree commits (as opposed to e.g. flatpak as well as
things like rpm-ostree's pkgcache refs).
Eventually, I'd like to ensure everyone is using this and
hard require this metadata key for the
ostree admin deployflow - mainly to prevent accidents.