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 On Tue, Sep 29, 2015 at 3:58 PM, Colin Walters <[email protected]> wrote: > Hi, > > On Tue, Sep 29, 2015, at 05:53 AM, Natale Vinto wrote: > > > > This let containers hosts being updated silently by pushing the update > > remotely (solicitate an upgrade) and perform a reboot based some > > strategies, where the most useful is the one that let the cluster of > > hosts decide itself what system to reboot, thanks to a lock in the > > etcd distribuited key-value store, that ensure rebooting only not busy > > container hosts. > > We recently landed a "daemon" mode for rpm-ostree which should > help implement higher-level logic around host updates. I'd like > to integrate a default "timer" option soon. > > That said, what I think we really want here is for Kubernetes > to be in charge of scheduling host updates. It could > move pods *before* rebooting a host to ensure that there's > no downtime. > >
