-
Notifications
You must be signed in to change notification settings - Fork 24
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
Flesh out and document target UX #8
Comments
The questions presuppose that upgrades aren't on by default which...hasn't been decided I'd say. It might be that e.g. FCOS ships with bootupd on by default.
Should it? Should |
I'm currently leaning towards having no updates by default and also documenting how one can use a container to orchestrate bootupd. |
WDYT about the discussions in coreos/fedora-coreos-tracker#510 (comment)? It seems like for EFI at least, it seems possible to make updates quite safe. In which case, it might be worthwhile to just always update to simplify the model and maintenance. (Obviously doesn't help BIOS of course). |
I think it would be really useful for Edit: thinking more on this... on the fence as well I think. I think it makes sense to have it in |
OK so clearly we want things to be configurable. There's the question of the default, but I think what we basically want is to support:
So for FCOS I think my vote would be off by default, it's trivial today to enable a systemd unit via Ignition/fcct so if we ship Now a general concern here is people running clusters will want to avoid the possibility of bricking multiple servers at once. For the MCO case that should already happen anyways if we enable That said there is still the overall concern that ostree updates are transactional, bootloader updates aren't - some admins may want to schedule the latter separately and be prepared for recovery in the (unlikely but possible) event things go wrong. |
Sorry for the late feedback, I also have some doubts on the UX, especially regarding auto-updates.
This would be a sweet-spot in terms of tackling updates cluster-wide, because otherwise a bootloader update requires two reboots: the first to have the ostree content available and the second to actually use the new bootloader.
From ContainerLinux experience, this a ticking bomb with a deferred explosion triggered by any reboot, which is better to avoid. It's problematic because an external unplanned event (kernel crash, power glitch, VM restart, etc) may activate an update at the worst possible time, possible compounding on other troubles and making root-cause analysis way messier. The current rpm-ostree approach of locked finalization (i.e. with a final apply&reboot atomic action) is a better model. |
Agreed. Another reason is that doing it pre-reboot you find out immediately if the bootloader update breaks your boot and so the rollout stops on the first machine instead of bricking your whole cluster. That said, I don't want to go back to coreos/rpm-ostree#1882. I'd much prefer for tighter integration between rpm-ostree and bootupd, which I think then meshes well with having it in This does go counter though to the "offline background updates" story. But there is only one bootloader, so there can never really be "offline updates" in the same way (though see #8 (comment)). |
Hmm actually, maybe a more correct way to do this is to integrate at the finalization stage just like |
In practice today I think two things are true:
Given this, a simple systemd unit like this:
is going to be fine for many people to start, or they could just do it manually. Now, I do agree with the concerns above. I filed that as #108 |
I think it's a useful exercise to early on flesh out what the UX will look like. Let's discuss that here and then add something in the README?
Some bootstrapping questions:
rpm-ostree status
on rpm-ostree-based systems?We don't need to answer everything completely, but discussing these will make it easier to think about how bootupd fits in.
The text was updated successfully, but these errors were encountered: