Based on what I gather from the link, the
CoreOS Update Strategy is really a reboot strategy with something pulling updates on a regular basis.
`atomic host upgrade` from cron would serve the same basis as the "automatic updates" with the potential changes Colin mentioned could provide another option.
But, like CoreOS, nothing happens until a reboot, and the reboot is the part that needs the most attention. There's no mention of how the locking mechanism works in conjunction with a container orchestration layer like kubernetes. How does container rescheduling of a busy node work? How does lock acquisition happen?
I think downloading new trees is a fairly simple and trivial problem, but how do you properly update a cluster of Atomic hosts should involve a higher level orchestration tool that understand the workloads, the cluster orchestration, and the host OS issues involved.
- Matt M