[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Adding a node to the cluster without ansible



Thanks you Jason. That would be good for both origin and enterprise customers. 

-- 
Srinivas Kotaru

From: Jason DeTiberus <jdetiber redhat com>
Date: Thursday, February 4, 2016 at 10:38 AM
To: skotaru <skotaru cisco com>
Cc: v <vekt0r7 gmx net>, "users lists openshift redhat com" <users lists openshift redhat com>
Subject: Re: Adding a node to the cluster without ansible



On Thu, Feb 4, 2016 at 1:31 PM, Srinivas Naga Kotaru (skotaru) <skotaru cisco com> wrote:
Thanks Jason for explanation

It answer few my questions. Today only am aware that we have to run the scaleup.yaml and create a new node group. 

I heard some complaints in the community as well as my internal team about overwriting config changes when ran the ansible playbook. Am sure we might be using existing node group while adding new nodes. 

This was the case a while back (3.0 Timeframe) and I believe we are not officially supporting the scaleup playbook for 3.0 deployments as well.

I do see that we are missing the documentation for using the playbooks to add a node for 3.1, so I'll go ahead and work on getting those added.
 

Please take a look at existing documentation and modify with this new data if not already there. 

-- 
Srinivas Kotaru

From: Jason DeTiberus <jdetiber redhat com>
Date: Thursday, February 4, 2016 at 10:24 AM
To: skotaru <skotaru cisco com>
Cc: v <vekt0r7 gmx net>, "users lists openshift redhat com" <users lists openshift redhat com>

Subject: Re: Adding a node to the cluster without ansible



On Thu, Feb 4, 2016 at 1:04 PM, Srinivas Naga Kotaru (skotaru) <skotaru cisco com> wrote:
Will ansible will touch existing configuration  and by any chance it will  overwrite custom config put into ? 

If running the full configuration playbooks, yes Ansible will overwrite custom configuration of the following files (at least):
- /etc/origin/master/master-config.yaml
- /etc/origin/master/scheduler.json
- /etc/origin/node/node-config.yaml
- /etc/sysconfig/{origin,atomic-enterprise}-*
- systemd unit files for ha master services
- /etc/sysconfig/docker
- ...

The goals of the configuration playbooks are to be able to continually manage a system in addition to installation.

If running the upgrade playbooks, we limit the changes made to the configuration files to the limit subset of configuration that we need to update. We use a custom ansible module to read in the YAML files, process the limited changes and write the file back out.


If you are running the scaleup.yml playbook, the only tasks done on the master(s) (other than gather facts from them), is to generate the new certificates/kubeconfigs for the new nodes. The playbook then goes on to configure the new nodes only (leaving the existing nodes untouched). This does require defining the new nodes in a [new_nodes] group instead of just adding them onto the [nodes] group. 


Just adding a new node, steps required looks scare me ( both ansible and manual). Can we do better job here by automating this task and guaranteed no disruption to existing cluster health?

The scaleup.yml playbook already does this. If your environment was installed with the openshift-ansible-installer, then you can also use that tool for configuring the new nodes as well. Eventually the installer tool will be able to work against a previously installed cluster, but we still have a bit of work to make that happen.
 

My worry about real prod environments and always uptime guaranteed with SLA’s. 

-- 
Srinivas Kotaru





--
Jason DeTiberus



--
Jason DeTiberus

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]