Skip to content
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

Don't require adoption for FCOS #103

Closed
cgwalters opened this issue Nov 11, 2020 · 0 comments · Fixed by #104
Closed

Don't require adoption for FCOS #103

cgwalters opened this issue Nov 11, 2020 · 0 comments · Fixed by #104

Comments

@cgwalters
Copy link
Member

I think we should be confident enough in our process that bootupctl update should detect the FCOS case and update it transparently.

cgwalters added a commit to cgwalters/bootupd that referenced this issue Nov 11, 2020
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
openshift-merge-robot pushed a commit that referenced this issue Nov 13, 2020
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: #103
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant