[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Quorum-based voting for system upgrade

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 <walters verbum org> wrote:

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]