481 lines
20 KiB
YAML
Raw Normal View History

heat_template_version: queens
description: >
MySQL service deployment with pacemaker bundle
parameters:
DockerMysqlImage:
description: image
type: string
DockerMysqlConfigImage:
description: The container image to use for the mysql config_volume
type: string
EndpointMap:
default: {}
description: Mapping of service endpoint -> protocol. Typically set
via parameter_defaults in the resource registry.
type: json
ServiceData:
default: {}
description: Dictionary packing service data
type: json
ServiceNetMap:
default: {}
description: Mapping of service_name -> network name. Typically set
via parameter_defaults in the resource registry. This
mapping overrides those in ServiceNetMapDefaults.
type: json
DefaultPasswords:
default: {}
type: json
MysqlRootPassword:
type: string
hidden: true
default: ''
MysqlClustercheckPassword:
type: string
hidden: true
RoleName:
default: ''
description: Role name on which the service is applied
type: string
RoleParameters:
default: {}
description: Parameters specific to the role
type: json
EnableInternalTLS:
type: boolean
default: false
InternalTLSCAFile:
default: '/etc/ipa/ca.crt'
type: string
description: Specifies the default CA cert to use if TLS is used for
services in the internal network.
ConfigDebug:
default: false
description: Whether to run config management (e.g. Puppet) in debug mode.
type: boolean
DeployIdentifier:
default: ''
type: string
description: >
Setting this to a unique value will re-run any deployment tasks which
perform configuration on a Heat stack-update.
resources:
ContainersCommon:
type: ../../containers-common.yaml
MysqlPuppetBase:
type: ../../../../puppet/services/pacemaker/database/mysql.yaml
properties:
EndpointMap: {get_param: EndpointMap}
ServiceData: {get_param: ServiceData}
ServiceNetMap: {get_param: ServiceNetMap}
DefaultPasswords: {get_param: DefaultPasswords}
RoleName: {get_param: RoleName}
RoleParameters: {get_param: RoleParameters}
conditions:
puppet_debug_enabled: {get_param: ConfigDebug}
internal_tls_enabled: {equals: [{get_param: EnableInternalTLS}, true]}
outputs:
role_data:
description: Containerized service MySQL using composable services.
value:
service_name: {get_attr: [MysqlPuppetBase, role_data, service_name]}
config_settings:
map_merge:
- {get_attr: [MysqlPuppetBase, role_data, config_settings]}
- tripleo::profile::pacemaker::database::mysql_bundle::mysql_docker_image: &mysql_image_pcmklatest
list_join:
- ':'
- - yaql:
data: {get_param: DockerMysqlImage}
expression: $.data.rightSplit(separator => ":", maxSplits => 1)[0]
- 'pcmklatest'
tripleo::profile::pacemaker::database::mysql_bundle::control_port: 3123
tripleo.mysql.firewall_rules:
'104 mysql galera-bundle':
dport:
- 873
- 3123
- 3306
- 4444
- 4567
- 4568
- 9200
tripleo::profile::pacemaker::database::mysql_bundle::bind_address:
str_replace:
template:
"%{hiera('fqdn_$NETWORK')}"
params:
$NETWORK: {get_param: [ServiceNetMap, MysqlNetwork]}
-
if:
- internal_tls_enabled
-
tripleo::profile::pacemaker::database::mysql_bundle::ca_file:
get_param: InternalTLSCAFile
- {}
logging_source: {get_attr: [MysqlPuppetBase, role_data, logging_source]}
logging_groups: {get_attr: [MysqlPuppetBase, role_data, logging_groups]}
# BEGIN DOCKER SETTINGS #
puppet_config:
config_volume: mysql
puppet_tags: file # set this even though file is the default
step_config:
list_join:
- "\n"
- - "['Mysql_datadir', 'Mysql_user', 'Mysql_database', 'Mysql_grant', 'Mysql_plugin'].each |String $val| { noop_resource($val) }"
- "exec {'wait-for-settle': command => '/bin/true' }"
- "include ::tripleo::profile::pacemaker::database::mysql_bundle"
config_image: {get_param: DockerMysqlConfigImage}
kolla_config:
/var/lib/kolla/config_files/mysql.json:
command: /usr/sbin/pacemaker_remoted
config_files:
- dest: /etc/libqb/force-filesystem-sockets
source: /dev/null
owner: root
perm: '0644'
- source: "/var/lib/kolla/config_files/src/*"
dest: "/"
merge: true
preserve_properties: true
- source: "/var/lib/kolla/config_files/src-tls/*"
dest: "/"
merge: true
optional: true
preserve_properties: true
permissions:
- path: /var/log/mysql
owner: mysql:mysql
recurse: true
- path: /etc/pki/tls/certs/mysql.crt
owner: mysql:mysql
perm: '0600'
optional: true
- path: /etc/pki/tls/private/mysql.key
owner: mysql:mysql
perm: '0600'
optional: true
docker_config_scripts: {get_attr: [ContainersCommon, docker_config_scripts]}
docker_config:
step_1:
mysql_data_ownership:
start_order: 0
detach: false
image: {get_param: DockerMysqlImage}
net: host
user: root
# Kolla does only non-recursive chown
command: ['chown', '-R', 'mysql:', '/var/lib/mysql']
volumes:
- /var/lib/mysql:/var/lib/mysql
mysql_bootstrap:
start_order: 1
detach: false
image: {get_param: DockerMysqlImage}
net: host
user: root
# Kolla bootstraps aren't idempotent, explicitly checking if bootstrap was done
command:
- 'bash'
Add --wsrep-provider=none to the mysql_bootstrap container Depending on the version of mariadb/galera installed the mysql_bootstrap command might fail. With the following unrevealing error: openstack-mariadb-docker:2017-08-28.10 "bash -ec 'if [ -e /v" 3 hours ago Exited (124) 3 hours ago The timeout is actually due to the fact that the following snippets does not complete within 60 seconds: """ if [ -e /var/lib/mysql/mysql ]; then exit 0; fi kolla_start mysqld_safe --skip-networking --wsrep-on=OFF & timeout ${DB_MAX_TIMEOUT} /bin/bash -c ''until mysqladmin -uroot -p"${DB_ROOT_PASSWORD}" ping 2>/dev/null; do sleep 1; done'' mysql -uroot -p"${DB_ROOT_PASSWORD}" -e "CREATE USER ''clustercheck''@''localhost'' IDENTIFIED BY '${DB_CLUSTERCHECK_PASSWORD}'';" mysql -uroot -p"${DB_ROOT_PASSWORD}" -e "GRANT PROCESS ON *.* TO ''clustercheck' """ The problem is that with older mariadb versions: galera-25.3.16-3.el7ost.x86_64 mariadb-5.5.56-2.el7.x86_64 The mysqld_safe process starts in galera mode (as opposed as to single local mode): 170830 17:03:05 [Note] WSREP: Start replication 170830 17:03:05 [Note] WSREP: GMCast version 0 ... 170830 17:03:05 [ERROR] WSREP: wsrep::connect() failed: 7 170830 17:03:05 [ERROR] Aborting That means that even though we specified --wsrep-on=OFF it is still starting in cluster mode. Let's add the extra --wsrep-provider=none which older versions required. Let's also add a '-x' to this transient container as that would have helped a bit because we would have understood right away that it was mysqld_safe that was not starting. I tested this successfully on an environment that showed the problem. The new option is still accepted by newer DB versions in any case. Closes-Bug: #1714057 Change-Id: Icf67fd2fbf520e8a62405b4d49e8d5169ff3925b Co-Authored-By: Mike Bayer <mbayer@redhat.com>
2017-08-30 19:26:43 +02:00
- '-ecx'
-
list_join:
- "\n"
- - 'if [ -e /var/lib/mysql/mysql ]; then exit 0; fi'
- 'echo -e "\n[mysqld]\nwsrep_provider=none" >> /etc/my.cnf'
- 'sudo -u mysql -E kolla_start'
- 'mysqld_safe --skip-networking --wsrep-on=OFF &'
- 'timeout ${DB_MAX_TIMEOUT} /bin/bash -c ''until mysqladmin -uroot -p"${DB_ROOT_PASSWORD}" ping 2>/dev/null; do sleep 1; done'''
- 'mysql -uroot -p"${DB_ROOT_PASSWORD}" -e "CREATE USER ''clustercheck''@''localhost'' IDENTIFIED BY ''${DB_CLUSTERCHECK_PASSWORD}'';"'
- 'mysql -uroot -p"${DB_ROOT_PASSWORD}" -e "GRANT PROCESS ON *.* TO ''clustercheck''@''localhost'' WITH GRANT OPTION;"'
- 'timeout ${DB_MAX_TIMEOUT} mysqladmin -uroot -p"${DB_ROOT_PASSWORD}" shutdown'
volumes: &mysql_volumes
list_concat:
- {get_attr: [ContainersCommon, volumes]}
-
- /var/lib/kolla/config_files/mysql.json:/var/lib/kolla/config_files/config.json
- /var/lib/config-data/puppet-generated/mysql/:/var/lib/kolla/config_files/src:ro
- /var/lib/mysql:/var/lib/mysql
environment:
- KOLLA_CONFIG_STRATEGY=COPY_ALWAYS
- KOLLA_BOOTSTRAP=True
- DB_MAX_TIMEOUT=60
-
list_join:
- '='
- - 'DB_CLUSTERCHECK_PASSWORD'
- {get_param: MysqlClustercheckPassword}
-
list_join:
- '='
- - 'DB_ROOT_PASSWORD'
-
yaql:
expression: $.data.passwords.where($ != '').first()
data:
passwords:
- {get_param: MysqlRootPassword}
- {get_param: [DefaultPasswords, mysql_root_password]}
mysql_image_tag:
start_order: 2
detach: false
net: host
user: root
command:
- '/bin/bash'
- '-c'
- str_replace:
template:
"/usr/bin/docker tag 'MYSQL_IMAGE' 'MYSQL_IMAGE_PCMKLATEST'"
params:
MYSQL_IMAGE: {get_param: DockerMysqlImage}
MYSQL_IMAGE_PCMKLATEST: *mysql_image_pcmklatest
image: {get_param: DockerMysqlImage}
volumes:
- /etc/hosts:/etc/hosts:ro
- /etc/localtime:/etc/localtime:ro
- /dev/shm:/dev/shm:rw
- /etc/sysconfig/docker:/etc/sysconfig/docker:ro
- /usr/bin:/usr/bin:ro
- /var/run/docker.sock:/var/run/docker.sock:rw
step_2:
mysql_init_bundle:
start_order: 1
detach: false
net: host
user: root
command: # '/docker_puppet_apply.sh "STEP" "TAGS" "CONFIG" "DEBUG"'
list_concat:
- - '/docker_puppet_apply.sh'
- '2'
- 'file,file_line,concat,augeas,pacemaker::resource::bundle,pacemaker::property,pacemaker::resource::ocf,pacemaker::constraint::order,pacemaker::constraint::colocation,galera_ready,mysql_database,mysql_grant,mysql_user'
- 'include ::tripleo::profile::base::pacemaker;include ::tripleo::profile::pacemaker::database::mysql_bundle'
- if:
- puppet_debug_enabled
- - '--debug'
- - ''
image: {get_param: DockerMysqlImage}
volumes:
list_concat:
- {get_attr: [ContainersCommon, docker_puppet_apply_volumes]}
- - /etc/corosync/corosync.conf:/etc/corosync/corosync.conf:ro
- /dev/shm:/dev/shm:rw
- /var/lib/mysql:/var/lib/mysql:rw
environment:
# NOTE: this should force this container to re-run on each
# update (scale-out, etc.)
- list_join:
- ''
- - 'TRIPLEO_DEPLOY_IDENTIFIER='
- {get_param: DeployIdentifier}
host_prep_tasks:
- name: create persistent directories
file:
path: "{{ item }}"
state: directory
with_items:
- /var/log/containers/mysql
- /var/lib/mysql
- name: mysql logs readme
copy:
dest: /var/log/mariadb/readme.txt
content: |
Log files from mysql containers can be found under
/var/log/containers/mysql.
ignore_errors: true
metadata_settings:
get_attr: [MysqlPuppetBase, role_data, metadata_settings]
update_tasks:
- name: Mariadb fetch and retag container image for pacemaker
when: step|int == 2
block: &mysql_fetch_retag_container_tasks
- name: Get docker Mariadb image
set_fact:
docker_image: {get_param: DockerMysqlImage}
docker_image_latest: *mysql_image_pcmklatest
- name: Get previous Mariadb image id
Upgrade: make bundles use new container image name after upgrade The major_upgrade tasks for HA services only allows to change the container image tag used by bundles. It doesn't work when the image name changes. Fix this unwanted behaviour by updating the bundle's attribute in pacemaker to use container image <NEW>:pcmklatest instead of <CURRENT>:pcmklatest We are constrained by the steps at when we can modify the bundle: . Image update must stay at step 3 when pacemaker is stopped. . image name used by the bundle must be available in docker when the bundle is updated So we re-use the double tagging idiom to perform the image update: . At step 0, we tag the image pointed to by <CURRENT>:pcmklatest with an additional temporary tag <NEW>:pcmklatest. => this ensures that at step1, the new tag is available on all controller nodes. . At step 1, we update the resource bundle to use the new image name <NEW>:pcmklatest. => at the end of step1, the bundle will be configured with the new name, and be able to start even if the real container image hasn't be pulled yet. . At step 3, the existing code will download the real image <NEW>:<NEWTAG> and make tag <NEW>:pcmklatest point to it. Since the bundle is always modified, we now stop and restart the bundle resources unconditionally. Also, move the mariadb upgrade task to step 3, when pacemaker is guaranteed to be stopped, because the task assumes that no mysql is running while it runs. Fix the mysql permission after rpm upgrade on the host. Change-Id: Ic87a66753b104b9f15db70fdccbd66d88cef94df Closes-Bug: #1763001
2018-04-11 11:57:59 +00:00
shell: "docker images | awk '/mariadb.* pcmklatest/{print $3}' | uniq"
register: mariadb_image_id
- block:
- name: Get a list of container using Mariadb image
shell: "docker ps -a -q -f 'ancestor={{mariadb_image_id.stdout}}'"
register: mariadb_containers_to_destroy
# It will be recreated with the delpoy step.
- name: Remove any container using the same Mariadb image
shell: "docker rm -fv {{item}}"
with_items: "{{ mariadb_containers_to_destroy.stdout_lines }}"
- name: Remove previous Mariadb images
shell: "docker rmi -f {{mariadb_image_id.stdout}}"
when:
- mariadb_image_id.stdout != ''
- name: Pull latest Mariadb images
command: "docker pull {{docker_image}}"
- name: Retag pcmklatest to latest Mariadb image
shell: "docker tag {{docker_image}} {{docker_image_latest}}"
# Got to check that pacemaker_is_active is working fine with bundle.
# TODO: pacemaker_is_active resource doesn't support bundle.
upgrade_tasks:
- name: Get docker Mysql image
set_fact:
Upgrade: make bundles use new container image name after upgrade The major_upgrade tasks for HA services only allows to change the container image tag used by bundles. It doesn't work when the image name changes. Fix this unwanted behaviour by updating the bundle's attribute in pacemaker to use container image <NEW>:pcmklatest instead of <CURRENT>:pcmklatest We are constrained by the steps at when we can modify the bundle: . Image update must stay at step 3 when pacemaker is stopped. . image name used by the bundle must be available in docker when the bundle is updated So we re-use the double tagging idiom to perform the image update: . At step 0, we tag the image pointed to by <CURRENT>:pcmklatest with an additional temporary tag <NEW>:pcmklatest. => this ensures that at step1, the new tag is available on all controller nodes. . At step 1, we update the resource bundle to use the new image name <NEW>:pcmklatest. => at the end of step1, the bundle will be configured with the new name, and be able to start even if the real container image hasn't be pulled yet. . At step 3, the existing code will download the real image <NEW>:<NEWTAG> and make tag <NEW>:pcmklatest point to it. Since the bundle is always modified, we now stop and restart the bundle resources unconditionally. Also, move the mariadb upgrade task to step 3, when pacemaker is guaranteed to be stopped, because the task assumes that no mysql is running while it runs. Fix the mysql permission after rpm upgrade on the host. Change-Id: Ic87a66753b104b9f15db70fdccbd66d88cef94df Closes-Bug: #1763001
2018-04-11 11:57:59 +00:00
mysql_docker_image_latest: *mysql_image_pcmklatest
- name: Check for Mysql Kolla configuration
stat:
path: /var/lib/config-data/puppet-generated/mysql
register: mysql_kolla_config
- name: Check if Mysql is already containerized
set_fact:
mysql_containerized: "{{mysql_kolla_config.stat.isdir | default(false)}}"
- name: get bootstrap nodeid
tags: common
command: hiera -c /etc/puppet/hiera.yaml bootstrap_nodeid
register: bootstrap_node
- name: set is_bootstrap_node fact
tags: common
set_fact: is_bootstrap_node={{bootstrap_node.stdout|lower == ansible_hostname|lower}}
- name: Mysql baremetal to container upgrade tasks
when:
- step|int == 1
- not mysql_containerized|bool
block:
- name: Check cluster resource status
pacemaker_resource:
resource: galera
state: master
check_mode: true
ignore_errors: true
register: galera_res
- when: (is_bootstrap_node) and (galera_res|succeeded)
block:
- name: Disable the galera cluster resource
pacemaker_resource:
resource: galera
state: disable
wait_for_resource: true
register: output
retries: 5
until: output.rc == 0
- name: Delete the stopped galera cluster resource.
pacemaker_resource:
resource: galera
state: delete
wait_for_resource: true
register: output
retries: 5
until: output.rc == 0
- name: Disable mysql service
service: name=mariadb enabled=no
- name: Remove clustercheck service from xinetd
file: state=absent path=/etc/xinetd.d/galera-monitor
- name: Restart xinetd service after clustercheck removal
service: name=xinetd state=restarted
Upgrade: make bundles use new container image name after upgrade The major_upgrade tasks for HA services only allows to change the container image tag used by bundles. It doesn't work when the image name changes. Fix this unwanted behaviour by updating the bundle's attribute in pacemaker to use container image <NEW>:pcmklatest instead of <CURRENT>:pcmklatest We are constrained by the steps at when we can modify the bundle: . Image update must stay at step 3 when pacemaker is stopped. . image name used by the bundle must be available in docker when the bundle is updated So we re-use the double tagging idiom to perform the image update: . At step 0, we tag the image pointed to by <CURRENT>:pcmklatest with an additional temporary tag <NEW>:pcmklatest. => this ensures that at step1, the new tag is available on all controller nodes. . At step 1, we update the resource bundle to use the new image name <NEW>:pcmklatest. => at the end of step1, the bundle will be configured with the new name, and be able to start even if the real container image hasn't be pulled yet. . At step 3, the existing code will download the real image <NEW>:<NEWTAG> and make tag <NEW>:pcmklatest point to it. Since the bundle is always modified, we now stop and restart the bundle resources unconditionally. Also, move the mariadb upgrade task to step 3, when pacemaker is guaranteed to be stopped, because the task assumes that no mysql is running while it runs. Fix the mysql permission after rpm upgrade on the host. Change-Id: Ic87a66753b104b9f15db70fdccbd66d88cef94df Closes-Bug: #1763001
2018-04-11 11:57:59 +00:00
- name: Prepare the switch to new galera container image name in pacemaker
when:
- step|int == 0
- mysql_containerized|bool
block:
- name: Get galera image id currently used by pacemaker
shell: "docker images | awk '/mariadb.* pcmklatest/{print $3}' | uniq"
register: galera_current_pcmklatest_id
- name: Temporarily tag the current galera image id with the upgraded image name
shell: "docker tag {{galera_current_pcmklatest_id.stdout}} {{mysql_docker_image_latest}}"
- name: Disable the galera cluster resource before container upgrade
when:
- step|int == 1
- mysql_containerized|bool
- is_bootstrap_node
pacemaker_resource:
resource: galera
state: disable
wait_for_resource: true
register: output
retries: 5
until: output.rc == 0
- name: Move Mysql logging to /var/log/containers
when:
- step|int == 1
- mysql_containerized|bool
- is_bootstrap_node
block:
- name: Check Mysql logging configuration in pacemaker
command: cibadmin --query --xpath "//storage-mapping[@id='mysql-log']"
ignore_errors: true
register: mysql_logs_moved
- name: Change Mysql logging configuration in pacemaker
# rc == 6 means the configuration doesn't exist in the CIB
when: mysql_logs_moved.rc == 6
block:
- name: Add a bind mount for logging in the galera bundle
command: pcs resource bundle update galera-bundle storage-map add id=mysql-log source-dir=/var/log/containers/mysql target-dir=/var/log/mysql options=rw
- name: Reconfigure Mysql log file in the galera resource agent
command: pcs resource update galera log=/var/log/mysql/mysqld.log
Upgrade: make bundles use new container image name after upgrade The major_upgrade tasks for HA services only allows to change the container image tag used by bundles. It doesn't work when the image name changes. Fix this unwanted behaviour by updating the bundle's attribute in pacemaker to use container image <NEW>:pcmklatest instead of <CURRENT>:pcmklatest We are constrained by the steps at when we can modify the bundle: . Image update must stay at step 3 when pacemaker is stopped. . image name used by the bundle must be available in docker when the bundle is updated So we re-use the double tagging idiom to perform the image update: . At step 0, we tag the image pointed to by <CURRENT>:pcmklatest with an additional temporary tag <NEW>:pcmklatest. => this ensures that at step1, the new tag is available on all controller nodes. . At step 1, we update the resource bundle to use the new image name <NEW>:pcmklatest. => at the end of step1, the bundle will be configured with the new name, and be able to start even if the real container image hasn't be pulled yet. . At step 3, the existing code will download the real image <NEW>:<NEWTAG> and make tag <NEW>:pcmklatest point to it. Since the bundle is always modified, we now stop and restart the bundle resources unconditionally. Also, move the mariadb upgrade task to step 3, when pacemaker is guaranteed to be stopped, because the task assumes that no mysql is running while it runs. Fix the mysql permission after rpm upgrade on the host. Change-Id: Ic87a66753b104b9f15db70fdccbd66d88cef94df Closes-Bug: #1763001
2018-04-11 11:57:59 +00:00
- name: Update the galera bundle to use the new container image name
when:
- step|int == 1
- mysql_containerized|bool
- is_bootstrap_node
command: "pcs resource bundle update galera-bundle container image={{mysql_docker_image_latest}}"
- name: Enable the galera cluster resource
when:
- step|int == 1
- mysql_containerized|bool
- is_bootstrap_node
pacemaker_resource:
resource: galera
state: enable
wait_for_resource: true
register: output
retries: 5
until: output.rc == 0
- name: Retag the pacemaker image if containerized
when:
- step|int == 3
- mysql_containerized|bool
block: *mysql_fetch_retag_container_tasks
- name: Check and upgrade Mysql database after major version upgrade
Upgrade: make bundles use new container image name after upgrade The major_upgrade tasks for HA services only allows to change the container image tag used by bundles. It doesn't work when the image name changes. Fix this unwanted behaviour by updating the bundle's attribute in pacemaker to use container image <NEW>:pcmklatest instead of <CURRENT>:pcmklatest We are constrained by the steps at when we can modify the bundle: . Image update must stay at step 3 when pacemaker is stopped. . image name used by the bundle must be available in docker when the bundle is updated So we re-use the double tagging idiom to perform the image update: . At step 0, we tag the image pointed to by <CURRENT>:pcmklatest with an additional temporary tag <NEW>:pcmklatest. => this ensures that at step1, the new tag is available on all controller nodes. . At step 1, we update the resource bundle to use the new image name <NEW>:pcmklatest. => at the end of step1, the bundle will be configured with the new name, and be able to start even if the real container image hasn't be pulled yet. . At step 3, the existing code will download the real image <NEW>:<NEWTAG> and make tag <NEW>:pcmklatest point to it. Since the bundle is always modified, we now stop and restart the bundle resources unconditionally. Also, move the mariadb upgrade task to step 3, when pacemaker is guaranteed to be stopped, because the task assumes that no mysql is running while it runs. Fix the mysql permission after rpm upgrade on the host. Change-Id: Ic87a66753b104b9f15db70fdccbd66d88cef94df Closes-Bug: #1763001
2018-04-11 11:57:59 +00:00
when: step|int == 3
block:
Upgrade: make bundles use new container image name after upgrade The major_upgrade tasks for HA services only allows to change the container image tag used by bundles. It doesn't work when the image name changes. Fix this unwanted behaviour by updating the bundle's attribute in pacemaker to use container image <NEW>:pcmklatest instead of <CURRENT>:pcmklatest We are constrained by the steps at when we can modify the bundle: . Image update must stay at step 3 when pacemaker is stopped. . image name used by the bundle must be available in docker when the bundle is updated So we re-use the double tagging idiom to perform the image update: . At step 0, we tag the image pointed to by <CURRENT>:pcmklatest with an additional temporary tag <NEW>:pcmklatest. => this ensures that at step1, the new tag is available on all controller nodes. . At step 1, we update the resource bundle to use the new image name <NEW>:pcmklatest. => at the end of step1, the bundle will be configured with the new name, and be able to start even if the real container image hasn't be pulled yet. . At step 3, the existing code will download the real image <NEW>:<NEWTAG> and make tag <NEW>:pcmklatest point to it. Since the bundle is always modified, we now stop and restart the bundle resources unconditionally. Also, move the mariadb upgrade task to step 3, when pacemaker is guaranteed to be stopped, because the task assumes that no mysql is running while it runs. Fix the mysql permission after rpm upgrade on the host. Change-Id: Ic87a66753b104b9f15db70fdccbd66d88cef94df Closes-Bug: #1763001
2018-04-11 11:57:59 +00:00
# mariadb package changes ownership of /var/lib/mysql on package
# update, so update here rather than in tripleo-package, to
# guarantee that ownership is fixed at the end of step 3
- name: Update host mariadb packages
when: step|int == 3
yum: name=mariadb-server-galera state=latest
- name: Mysql upgrade script
set_fact:
mysql_upgrade_script:
# idempotency: mysql_upgrade leaves a marker file
# in datadir, it does nothing if it has already been
# executed for the current version of MariaDB.
list_join:
- ' '
Upgrade: make bundles use new container image name after upgrade The major_upgrade tasks for HA services only allows to change the container image tag used by bundles. It doesn't work when the image name changes. Fix this unwanted behaviour by updating the bundle's attribute in pacemaker to use container image <NEW>:pcmklatest instead of <CURRENT>:pcmklatest We are constrained by the steps at when we can modify the bundle: . Image update must stay at step 3 when pacemaker is stopped. . image name used by the bundle must be available in docker when the bundle is updated So we re-use the double tagging idiom to perform the image update: . At step 0, we tag the image pointed to by <CURRENT>:pcmklatest with an additional temporary tag <NEW>:pcmklatest. => this ensures that at step1, the new tag is available on all controller nodes. . At step 1, we update the resource bundle to use the new image name <NEW>:pcmklatest. => at the end of step1, the bundle will be configured with the new name, and be able to start even if the real container image hasn't be pulled yet. . At step 3, the existing code will download the real image <NEW>:<NEWTAG> and make tag <NEW>:pcmklatest point to it. Since the bundle is always modified, we now stop and restart the bundle resources unconditionally. Also, move the mariadb upgrade task to step 3, when pacemaker is guaranteed to be stopped, because the task assumes that no mysql is running while it runs. Fix the mysql permission after rpm upgrade on the host. Change-Id: Ic87a66753b104b9f15db70fdccbd66d88cef94df Closes-Bug: #1763001
2018-04-11 11:57:59 +00:00
- - '{% if mysql_containerized %}kolla_set_configs; {% endif %}'
- 'chown -R mysql:mysql /var/lib/mysql;'
- 'mysqld_safe --user=mysql --wsrep-provider=none --skip-networking --wsrep-on=off &'
- 'timeout 60 sh -c ''while ! mysqladmin ping --silent; do sleep 1; done'';'
- 'mysql_upgrade;'
- 'mysqladmin shutdown'
- name: Bind mounts for temporary container
set_fact:
mysql_upgrade_db_bind_mounts: *mysql_volumes
- name: Upgrade Mysql database from a temporary container
shell:
str_replace:
template:
'/usr/bin/docker run --rm --log-driver=syslog -u root --net=host UPGRADE_ENV UPGRADE_VOLUMES "UPGRADE_IMAGE" /bin/bash -ecx "UPGRADE_SCRIPT"'
params:
UPGRADE_ENV: '-e "KOLLA_CONFIG_STRATEGY=COPY_ALWAYS"'
UPGRADE_IMAGE: *mysql_image_pcmklatest
UPGRADE_VOLUMES: "-v {{ mysql_upgrade_db_bind_mounts | union(['/tmp/mariadb-upgrade:/var/log/mariadb:rw']) | join(' -v ')}}"
UPGRADE_SCRIPT: "{{mysql_upgrade_script}}"
when: mysql_containerized|bool
- name: Upgrade Mysql database from the host
shell: /bin/bash -ecx "{{mysql_upgrade_script}}"
when: not mysql_containerized|bool