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

docs/atomic-rollbacks: Add a section on rollbacks #3171

Merged
merged 1 commit into from
Feb 13, 2024

Conversation

ericcurtin
Copy link
Collaborator

Describing how different types of rollbacks work.

@ericcurtin ericcurtin force-pushed the docs-alternate-rollbacks branch 3 times, most recently from 6ddb3d9 to a7529c5 Compare February 13, 2024 11:46
@ericcurtin
Copy link
Collaborator Author

Here is how is looks in .pdf format:

Atomic Rollbacks _ ostreedev_ostree.pdf

docs/adapting-existing.md Show resolved Hide resolved
docs/atomic-rollbacks.md Outdated Show resolved Hide resolved
docs/atomic-rollbacks.md Outdated Show resolved Hide resolved

set -ex

if [ "$(ostree admin status -D)" = "not-default" ]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine, that said...now that we've done all this I am still coming around to the idea that ostree should automatically inject something like ostree.fallback=/path/to/root for all non-default entries, that way we can reliably detect this from the initramfs and properly set up the default target from the initramfs.

Anyways, something to just consider for later.

Copy link
Collaborator Author

@ericcurtin ericcurtin Feb 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We normally fallback at the bootloader level right? So if we have loaded a kernel+initrd+cmdline from a fallback boot entry the ostree= karg would have the fallback root and ostree.fallback= would have the next fallback if that makes sense.

Also... cmdlines are generated server-side, this wouldn't be able to account for clients that missed an upgrade.

You can skip an upgrade in ostree right, if you haven't upgraded in a while?

That's why it's kinda nice to have the /boot/loader data client-side, fallbacks seem like something that should be client-side determined. Because each client may have a different upgrade path (and different fallback versions, or the fallback could be on A on some clients and B on others).

Describing how different types of rollbacks work.

Signed-off-by: Eric Curtin <ecurtin@redhat.com>
@ericcurtin
Copy link
Collaborator Author

Addressed comments and re-pushed

@cgwalters cgwalters merged commit eeccac7 into ostreedev:main Feb 13, 2024
22 of 23 checks passed
@ericcurtin ericcurtin deleted the docs-alternate-rollbacks branch February 13, 2024 18:12
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 this pull request may close these issues.

2 participants