On Thu, May 19, 2016 at 4:31 PM, Jeremy Eder <je...@redhat.com> wrote:
> Would commissaire be intended to address the case where I want to adjust > config options across a cluster? (openshift node or master configs) > >From my biased perspective, I would say no. I would expect that to be handled by Ansible or some other configuration management tool. That said, there are proposals and work being done upstream to move a good bit of that configuration into the cluster itself. > > 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 > -- Jason DeTiberus
