Would commissaire be intended to address the case where I want to adjust config options across a cluster? (openshift node or master configs)
On Thu, May 19, 2016 at 3:57 PM, Derek Carr <dec...@redhat.com> wrote: > 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 >> > >> > >> > > -- -- Jeremy Eder
