On May 19, 2016 17:03, "Jason DeTiberus" <jdeti...@redhat.com> wrote:
>
>
>
> 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.
>

Yeah, the configmaps. That's specifically what I'm trying to dedupe w/
commissaire. Thanks Jason.

>
>>
>>
>> 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

Reply via email to