summaryrefslogtreecommitdiffstats
path: root/playbooks
diff options
context:
space:
mode:
Diffstat (limited to 'playbooks')
-rw-r--r--playbooks/common/openshift-cluster/upgrades/upgrade_control_plane.yml23
-rw-r--r--playbooks/openshift-etcd/private/upgrade_main.yml33
2 files changed, 33 insertions, 23 deletions
diff --git a/playbooks/common/openshift-cluster/upgrades/upgrade_control_plane.yml b/playbooks/common/openshift-cluster/upgrades/upgrade_control_plane.yml
index 9b5ba3482..baec057f9 100644
--- a/playbooks/common/openshift-cluster/upgrades/upgrade_control_plane.yml
+++ b/playbooks/common/openshift-cluster/upgrades/upgrade_control_plane.yml
@@ -3,29 +3,6 @@
# Upgrade Masters
###############################################################################
-# Prior to 3.6, openshift-ansible created etcd serving certificates
-# without a SubjectAlternativeName entry for the system hostname. The
-# SAN list in Go 1.8 is now (correctly) authoritative and since
-# openshift-ansible configures masters to talk to etcd hostnames
-# rather than IP addresses, we must correct etcd certificates.
-#
-# This play examines the etcd serving certificate SANs on each etcd
-# host and records whether or not the system hostname is missing.
-- name: Examine etcd serving certificate SAN
- hosts: oo_etcd_to_config
- tasks:
- - slurp:
- src: /etc/etcd/server.crt
- register: etcd_serving_cert
- - set_fact:
- __etcd_cert_lacks_hostname: "{{ (openshift.common.hostname not in (etcd_serving_cert.content | b64decode | lib_utils_oo_parse_certificate_san)) | bool }}"
-
-# Redeploy etcd certificates when hostnames were missing from etcd
-# serving certificate SANs.
-- import_playbook: ../../../openshift-etcd/redeploy-certificates.yml
- when:
- - true in hostvars | lib_utils_oo_select_keys(groups['oo_etcd_to_config']) | lib_utils_oo_collect('__etcd_cert_lacks_hostname') | default([false])
-
- name: Backup and upgrade etcd
import_playbook: ../../../openshift-etcd/private/upgrade_main.yml
diff --git a/playbooks/openshift-etcd/private/upgrade_main.yml b/playbooks/openshift-etcd/private/upgrade_main.yml
index 8997680f9..fea588260 100644
--- a/playbooks/openshift-etcd/private/upgrade_main.yml
+++ b/playbooks/openshift-etcd/private/upgrade_main.yml
@@ -1,4 +1,37 @@
---
+# Prior to 3.6, openshift-ansible created etcd serving certificates
+# without a SubjectAlternativeName entry for the system hostname. The
+# SAN list in Go 1.8 is now (correctly) authoritative and since
+# openshift-ansible configures masters to talk to etcd hostnames
+# rather than IP addresses, we must correct etcd certificates.
+#
+# This play examines the etcd serving certificate SANs on each etcd
+# host and records whether or not the system hostname is missing.
+- name: Examine etcd serving certificate SAN
+ hosts: oo_etcd_to_config
+ tasks:
+ - slurp:
+ src: /etc/etcd/server.crt
+ register: etcd_serving_cert
+ - set_fact:
+ __etcd_cert_lacks_hostname: "{{ (openshift.common.hostname not in (etcd_serving_cert.content | b64decode | lib_utils_oo_parse_certificate_san)) | bool }}"
+
+# Redeploy etcd certificates when hostnames were missing from etcd
+# serving certificate SANs.
+- import_playbook: redeploy-certificates.yml
+ when:
+ - true in hostvars | lib_utils_oo_select_keys(groups['oo_etcd_to_config']) | lib_utils_oo_collect('__etcd_cert_lacks_hostname') | default([false])
+
+- import_playbook: restart.yml
+ vars:
+ g_etcd_certificates_expired: "{{ ('expired' in (hostvars | lib_utils_oo_select_keys(groups['etcd']) | lib_utils_oo_collect('check_results.check_results.etcd') | lib_utils_oo_collect('health'))) | bool }}"
+ when:
+ - true in hostvars | lib_utils_oo_select_keys(groups['oo_etcd_to_config']) | lib_utils_oo_collect('__etcd_cert_lacks_hostname') | default([false])
+
+- import_playbook: ../../openshift-master/private/restart.yml
+ when:
+ - true in hostvars | lib_utils_oo_select_keys(groups['oo_etcd_to_config']) | lib_utils_oo_collect('__etcd_cert_lacks_hostname') | default([false])
+
# For 1.4/3.4 we want to upgrade everyone to etcd-3.0. etcd docs say to
# upgrade from 2.0.x to 2.1.x to 2.2.x to 2.3.x to 3.0.x. While this is a tedius
# task for RHEL and CENTOS it's simply not possible in Fedora unless you've