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

[Clayton Coleman <ccoleman redhat com>]

Can we articulate a policy driven update and how that would look?
I.e. what's the operational policy we'd want to enable - update all
nodes with a given label selector?  Maintain a certain percentage of
nodes available?  If we can describe it in enough detail, it's easy
enough to describe the scripted job that would accomplish it.

On Tue, Sep 29, 2015 at 9:58 PM, Colin Walters <walters verbum org> 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.
>