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

[SGhosh <sghosh redhat com>]

There are a couple of k8s PRs on node evacuation
https://github.com/kubernetes/kubernetes/issues/6080
https://github.com/kubernetes/kubernetes/issues/3885

So either OpenShift evacuation, or K8s evacution could free up the node, and the daemon mode that Colin mentioned could be leveraged by an external manager to perform the upgrade/reboot in a controlled manner.

One other code element is the oVirt Upgrade Manager:
http://www.ovirt.org/Home/Features/UpgradeManager

Making that ostree aware and able to talk to Atomic host's rpm-ostree daemon would enable centralized cluster-wide host management.

-subhendu


On 09/29/2015 04:25 PM, Tim St. Clair wrote:

k8s is missing the notion of maintenance primitives, for cross ref : https://mesos.apache.org/documentation/latest/maintenance/ ... My google fu has failed me on what YARN does, but they do similar things. 

Use cases are pretty well defined, but would need to reinterpreted for k8's. 

Cheers,

Tim

On Tue, Sep 29, 2015 at 2: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.

--

Cheers,

Timothy St. Clair

tstclair redhat com