Update all {F,RH}CoreOS systems that have an aleph version #104
Conversation
Came up in review in coreos/fedora-coreos-docs#203 Basically it's confusing to users that they need to understand the difference between `update` and `adopt-and-update`. From bootupd's perspective these are quite different things; the first case is a completely known quantity, the second isn't. However...we can be pretty confident that we can update systems that have a CoreOS aleph version (i.e. they were generated by coreos-assembler), since we haven't changed how the bootloader is installed there really much at all. This means that for now RHCOS 4.{1,2} bootimages that were generated via Anaconda will still require `adopt-and-update`, but detecting and validating that can come as a second phase. The high level logic here is that the status gains a new `confident: bool` flag (which corresponds right now to "have CoreOS aleph"). The client side looks at this and automatically bridges the `update` CLI to `adopt-and-update`. Closes: coreos#103
|
OK, this one has green CI. |
| @@ -106,7 +116,7 @@ pub(crate) struct Status { | |||
| /// Maps a component name to status | |||
| pub(crate) components: BTreeMap<String, ComponentStatus>, | |||
| /// Components that appear to be installed, not via bootupd | |||
| pub(crate) adoptable: BTreeMap<String, ContentMetadata>, | |||
| pub(crate) adoptable: BTreeMap<String, Adoptable>, | |||
There was a problem hiding this comment.
I think this change breaks the "stable format" premise stated in the docstring, but current CI does not catch this because the entry/map in example-status-v0.json fixture is empty.
Is that a problem, or is this breaking change still ok? To my understanding this data-structure is not persisted to disk, and the change only affects client compatibility.
There was a problem hiding this comment.
Yeah, this is a valid concern and you're right this sneaks by our tests today.
In the end, while we have bootupctl status --json I think the project is still in a "stabilizing" state - there aren't any known consumers of the JSON yet.
Hmm, probably we should add a simple "is up to date" API, since that's all that most consumers would care about.
|
/hold Leaving this pre-stamped in case the breaking change was intended and confirmed ok. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, lucab 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 |
|
Will address that in followup |
Pointed out in code review in coreos#104
Pointed out in code review in #104
Came up in review in coreos/fedora-coreos-docs#203
Basically it's confusing to users that they need to understand
the difference between
updateandadopt-and-update.From bootupd's perspective these are quite different things;
the first case is a completely known quantity, the second isn't.
However...we can be pretty confident that we can update systems
that have a CoreOS aleph version (i.e. they were generated by coreos-assembler),
since we haven't changed how the bootloader is installed there
really much at all.
This means that for now RHCOS 4.{1,2} bootimages that were
generated via Anaconda will still require
adopt-and-update,but detecting and validating that can come as a second phase.
The high level logic here is that the status gains a new
confident: boolflag (which corresponds right now to"have CoreOS aleph"). The client side looks at this
and automatically bridges the
updateCLI toadopt-and-update.Closes: #103