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 <walt...@verbum.org
<mailto:walt...@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
tstcl...@redhat.com <mailto:tstcl...@redhat.com>
