feat(status): display pinned deployments #1285
Conversation
p5
force-pushed
the
readonly-pinning
branch
3 times, most recently
from
12f9499 to
82f0a72
Compare
Part of bootc-dev#904 Displays pinned deployments as part of "bootc status". Includes unit tests to ensure correct parsing of the pinned deployments, and that they are displayed in human readable formats correctly. Signed-off-by: Robert Sturla <[email protected]>
| fn human_render_imagestatus( | ||
| fn human_render_image_deployment( |
There was a problem hiding this comment.
I feel this function may need a larger rework than this PR can handle.
● Booted image: ghcr.io/rsturla/eternal-linux/lumina:42-nvidia-open
Digest: sha256:b1874fbb5f442657f3cc07a547c54292ca3f24fe828ab4f3132df4c9f23f1e3e (amd64)
Version: 250425 (2025-04-25T01:46:32Z)
Rollback image: ghcr.io/rsturla/eternal-linux/lumina:42-nvidia-open
Digest: sha256:b1874fbb5f442657f3cc07a547c54292ca3f24fe828ab4f3132df4c9f23f1e3e (amd64)
Version: 250425 (2025-04-25T01:46:32Z)
Rather than each block above being an "image", I feel it makes more sense being a "deployment" since it contains more information than just the image. For example, the index, pinned state, /usr overlay state etc. #1258 also updates this function to include HostStatus in order to access the /usr overlay state.
There was a problem hiding this comment.
Rather than each block above being an "image", I feel it makes more sense being a "deployment" since it contains more information than just the image.
Right, we can change the function to take a BootEntry instead right? Actually I went ahead and tried that, can you review #1291 and then we'll rebase on that?
| let pinned = deployments | ||
| .other | ||
| .iter() | ||
| .filter_map(|d| { | ||
| d.is_pinned() | ||
| .then(|| boot_entry_from_deployment(sysroot, d).ok()) | ||
| }) | ||
| .collect::<Option<Vec<_>>>() | ||
| .filter(|v| !v.is_empty()); |
There was a problem hiding this comment.
I think it feels duplicative to include the "primary" outputs (staged/booted/rollback) additionally in the pinned set.
WDYT about instead operating on the other deployment list?
Though that basically scope creeps into generally showing information about those arbitrary other deployments which we don't do now either.
There was a problem hiding this comment.
I think it feels duplicative to include the "primary" outputs (staged/booted/rollback) additionally in the pinned set.
In this case, the primary outputs are not duplicated into the "pinned" object. They are already filtered out before reaching this point (deployments.other excludes staged/booted/rollback).
I'm happy with this approach though, and instead of specifically storing pinned deployments inside the HostStatus, storing all other deployments as a BootEntry array.
| @@ -336,6 +346,7 @@ pub enum Slot { | |||
| Staged, | |||
| Booted, | |||
| Rollback, | |||
| Pinned, | |||
There was a problem hiding this comment.
If we follow the above suggestion I think instead of having a Slot for this we'd just display the other deployments unconditionally.
There was a problem hiding this comment.
What do you consider to be a "Slot"?
If we were operating on "Other" deployments, would these be considered "Other" slots? Or would these be deployments without a Slot?
My view as an outsider is of a "Slot" basically being a type of boot entry, where any image you're able to boot into should have a Slot, but I appreciate this probably isn't an accurate description once knowing the internals.
| fn human_render_imagestatus( | ||
| fn human_render_image_deployment( |
There was a problem hiding this comment.
Rather than each block above being an "image", I feel it makes more sense being a "deployment" since it contains more information than just the image.
Right, we can change the function to take a BootEntry instead right? Actually I went ahead and tried that, can you review #1291 and then we'll rebase on that?
Part of #904
Displays pinned deployments as part of "bootc status".
Includes unit tests to ensure correct parsing of the
pinned deployments, and that they are displayed in
human readable formats correctly.
Please find below how they look in both human and machine readable formats.
When the staged, booted or rollback deployments are pinned, the information is not duplicated in the outputs.
Please let me know if this output format is alright, or if you'd prefer some changes.
Human readable:
YAML:
YAML with rollback pinned: