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

[Natale Vinto <ebballon gmail com>]

Hi,
thanks for feedbacks. So, as far I understand, the logic (a module?)
between daemonized rpm-ostree and any kubernetes node evacuation
feature that move pods elsewhere, is responsible of upgrade and reboot
machines, like having a lock grant by kubernetes successful evacuation
operation.

The Orchestrator would be Kubernetes, and the daemon only an executor
with "grant" option?

What about some underline IaaS platform exists, as for Openstack,
would be Kubernetes to invoke for instance Compute API?



2015-09-29 22:13 GMT+02:00 Matt Micene <nzwulfin gmail com>:
> 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:
>>
>> 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.
>>
>



-- 
Natale Vinto
http://www.natalevinto.IT
FSF Member #8163
gpg keyserver: pool.sks-keyservers.net recv-keys 55260343
Key fingerprint = 71F1 12C2 035D 7082 0C0A  E677 8A85 5F78 5526 0343