Yep, definitely agreed - and it's not even implemented yet so I can't recommend people use it as a part of the overall procedure, but something to keep in mind in this problem space that this is one potential way of updating the cluster node agent and the daemons it manages in the future.
On Thu, May 19, 2016 at 3:25 PM, Jason DeTiberus <jdeti...@redhat.com> wrote: > > On May 19, 2016 2:59 PM, "Derek Carr" <dec...@redhat.com> wrote: > > > > Related: https://github.com/kubernetes/kubernetes/pull/23343 > > > > This is the model proposed by CoreOS for supporting cluster-upgrades. > Basically, a run-once kubelet is launched by the init system, and pulls > down the real kubelet to run as a container, then all other requisite host > services are provisioned as a DaemonSet derived set of pods on the node. > This does not cover things like kernel updates, but definitely does enable > a lot of scenarios for updates of kubelet/openshift-node if we adopted the > pattern. > > Definitely solves a large chunk of the problem. We still need to worry > about host upgrades, data center maintenance, etc. > > I'm all for the cluster owning all cluster upgrade related tasks, though. > > > > > Thanks, > > Derek > > > > > > > > > > > > > > On Thu, May 19, 2016 at 12:44 PM, Jason DeTiberus <jdeti...@redhat.com> > wrote: > >> > >> > >> On Thu, May 19, 2016 at 12:18 PM, Chmouel Boudjnah <chmo...@redhat.com> > wrote: > >>> > >>> Hello thanks for releasing this blog post, from a first impression > >>> there is a bit of an overlap if you are already cloudforms to do that, > >>> isn't it ? > >> > >> > >> With current implementations, yes. That said, Cloud Forms could > eventually switch to using Commissaire for managing clusters of hosts. > >> > >> As commissaire matures, I see great promise for it to handle a lot of > the complexity involved in managing complex cluster upgrades (think > OpenShift), where even something like applying kernel updates and > orchestrating a reboot of hosts requires much more consideration than apply > and restart or just performing the operations serially. Long term we need > something that can be more integrated with Kubernetes/OpenShift that will > allow for making ordering/restarting decisions on things like pod > placement, scheduler configuration, and disruption budgets (when they are > implemented). Having a centralized place to manage that complexity is much > better than having multiple external tools do the same. > >> > >> > >>> > >>> > >>> Chmouel > >>> > >>> On Thu, May 19, 2016 at 3:55 PM, Stephen Milner <smil...@redhat.com> > wrote: > >>> > Hello all, > >>> > > >>> > Have you heard about some kind of cluster host manager project and > >>> > want to learn more? Curious about what this Commissaire thing is that > >>> > has shown up in the Project Atomic GitHub repos? > >>> > The short answer is it is a lightweight REST interface for cluster > >>> > host management. For more information check out the introductory blog > >>> > post ... > >>> > > >>> > > http://www.projectatomic.io/blog/2016/05/introducing_commissaire/ > >>> > > >>> > ... and stay tuned for more in-depth posts for development and > >>> > operations in the near future! > >>> > > >>> > -- > >>> > Thanks, > >>> > Steve Milner > >>> > > >>> > >> > >> > >> > >> -- > >> Jason DeTiberus > > > > >
