Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1694102 - [DOC] Updating additional tasks when deprecating and adding master hosts on OCP 3.11
Summary: [DOC] Updating additional tasks when deprecating and adding master hosts on O...
Status: NEW
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 3.11.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Vikram Goyal
QA Contact: Xiaoli Tian
Vikram Goyal
Depends On:
TreeView+ depends on / blocked
Reported: 2019-03-29 14:14 UTC by Andre Costa
Modified: 2019-03-30 07:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

Description Andre Costa 2019-03-29 14:14:58 UTC
Document URL:

Section Number and Name: 
General process on both documents.

Describe the issue: 
On a case customer needed to deprecate their masters hosts to reinstall the OS and add the host back to Openshift cluster again. Doing this when starting with the first master in the [masters] group in the inventory, there are some tasks missing on our documentation that needs to be done, otherwise the add master host will fail due to some files that needed to be copied to other master. I replicate the process customer did and I had those issues as well.

Suggestions for improvement: 
First I think we would help the customers if we could aggregate both docs when it comes to deprecation and add masters on the cluster tasks or at least make some links between them on the tasks that are similar and important.
During my tests this was the extra me and customer needed to do when deprecating and adding back master 1 on OCP 3.11 cluster:

    # mkdir -p /etc/etcd/ca
    # scp <master1-hostname>:/etc/etcd/generated_certs/etcd_ca.tgz /etc/etcd/ca/
    # cp /etc/etcd/ca.crt /etc/etcd/ca/
    # cd /etc/etcd/ca/
    # tar xzf etcd_ca.tgz
    # scp <master1-hostname>:/etc/origin/master /etc/origin/master/ca.serial.txt

Then on the second master check for the etcd state as mentioned in our docs. As additional to that, and since the etcd scale up playbook will do it, I removed the first master as the member of etcd cluster (this also fixed a constant error I was having during the add_new_member task):

   # etcdctl3 --cacert="/etc/etcd/ca.crt" \
     --cert="/etc/etcd/peer.crt" \
     --key="/etc/etcd/peer.key" \
     --endpoints="https://<IP_MASTER2:2379,https://<IP_MASTER3>:2379" endpoint status -w table
# etcdctl3 --cacert="/etc/etcd/ca.crt" \
     --cert="/etc/etcd/peer.crt" \
     --key="/etc/etcd/peer.key" \
     --endpoints="https://<IP_MASTER2:2379,https://<IP_MASTER3>:2379" endpoint health -w table

# etcdctl3 --cacert="/etc/etcd/ca.crt" \
     --cert="/etc/etcd/peer.crt" \
     --key="/etc/etcd/peer.key" \
     --endpoints="https://<IP_MASTER2:2379,https://<IP_MASTER3>:2379" member list -w table

# etcdctl3 --cacert="/etc/etcd/ca.crt" \
     --cert="/etc/etcd/peer.crt" \
     --key="/etc/etcd/peer.key" \
     --endpoints="https://<IP_MASTER2:2379,https://<IP_MASTER3>:2379" member remove <MASTER1_MEMBERID>

Additional information:

Note You need to log in before you can comment on or make changes to this bug.