Compare commits
2 Commits
c8764159f6
...
fef97f0b04
Author | SHA1 | Date | |
---|---|---|---|
fef97f0b04 | |||
8ba0ca02b1 |
@ -271,10 +271,14 @@ pvc_autobackup:
|
|||||||
mount_cmds:
|
mount_cmds:
|
||||||
# This example shows an NFS mount leveraging the backup_root_path variable
|
# This example shows an NFS mount leveraging the backup_root_path variable
|
||||||
#- "/usr/sbin/mount.nfs -o nfsvers=3 10.0.0.10:/backups {backup_root_path}"
|
#- "/usr/sbin/mount.nfs -o nfsvers=3 10.0.0.10:/backups {backup_root_path}"
|
||||||
|
# This example shows an SSHFS mount leveraging the backup_root_path variable
|
||||||
|
#- "/usr/bin/sshfs user@hostname:/path {backup_root_path} -o default_permissions -o sshfs_sync -o IdentityFile=/path/to/id_rsa"
|
||||||
# These commands are executed at the end of the backup run and should unmount a filesystem
|
# These commands are executed at the end of the backup run and should unmount a filesystem
|
||||||
unmount_cmds:
|
unmount_cmds:
|
||||||
# This example shows a generic umount leveraging the backup_root_path variable
|
# This example shows a generic umount leveraging the backup_root_path variable
|
||||||
#- "/usr/bin/umount {backup_root_path}"
|
#- "/usr/bin/umount {backup_root_path}"
|
||||||
|
# This example shows an fusermount3 unmount (e.g. for SSHFS) leveraging the backup_root_path variable
|
||||||
|
#- "/usr/bin/fusermount3 -u {backup_root_path}"
|
||||||
|
|
||||||
# Configuration file networks
|
# Configuration file networks
|
||||||
# > Taken from base.yml's configuration; DO NOT MODIFY THIS SECTION.
|
# > Taken from base.yml's configuration; DO NOT MODIFY THIS SECTION.
|
||||||
|
@ -54,7 +54,7 @@ For each host in the cluster sequentially, do:
|
|||||||
|
|
||||||
## `upgrade-pvc-daemons.yml`
|
## `upgrade-pvc-daemons.yml`
|
||||||
|
|
||||||
This playbook performs a sequential upgrade of the PVC software daemons via apt on all nodes in a PVC cluster. This is a less invasive update process than the `update-pvc-cluster.yml` playbook as it does not flush or reboot the nodes, but does restart all PVC daemons (`pvcnoded`, `pvcapid`, and `pvcapid-worker`).
|
This playbook performs a sequential upgrade of the PVC software daemons via apt on all nodes in a PVC cluster. This is a less invasive update process than the `update-pvc-cluster.yml` playbook as it does not flush or reboot the nodes, but does restart all PVC daemons (`pvcnoded`, `pvcapid`, and `pvcworkerd`).
|
||||||
|
|
||||||
### Running the Playbook
|
### Running the Playbook
|
||||||
|
|
||||||
@ -84,7 +84,7 @@ For each node in the cluster sequentially, do:
|
|||||||
|
|
||||||
1. Secondary the node, then wait 30 seconds
|
1. Secondary the node, then wait 30 seconds
|
||||||
|
|
||||||
1. Restart both active PVC daemons (`pvcapid-worker`, `pvcnoded`), then wait 60 seconds; since the node is not the primary coordinator, `pvcapid` will not be running
|
1. Restart both active PVC daemons (`pvcworkerd`, `pvcnoded`), then wait 60 seconds; since the node is not the primary coordinator, `pvcapid` will not be running
|
||||||
|
|
||||||
1. Verify daemons are running
|
1. Verify daemons are running
|
||||||
|
|
||||||
|
@ -58,7 +58,7 @@
|
|||||||
state: restarted
|
state: restarted
|
||||||
enabled: yes
|
enabled: yes
|
||||||
with_items:
|
with_items:
|
||||||
- pvcapid-worker
|
- pvcworkerd
|
||||||
- pvcnoded
|
- pvcnoded
|
||||||
|
|
||||||
- name: wait 15 seconds for system to stabilize
|
- name: wait 15 seconds for system to stabilize
|
||||||
@ -76,7 +76,7 @@
|
|||||||
when: ansible_facts.services[item] is not defined or ansible_facts.services[item]["state"] != "running"
|
when: ansible_facts.services[item] is not defined or ansible_facts.services[item]["state"] != "running"
|
||||||
with_items:
|
with_items:
|
||||||
- pvcnoded.service
|
- pvcnoded.service
|
||||||
- pvcapid-worker.service
|
- pvcworkerd.service
|
||||||
|
|
||||||
- name: reset any systemd failures
|
- name: reset any systemd failures
|
||||||
command: systemctl reset-failed
|
command: systemctl reset-failed
|
||||||
|
Reference in New Issue
Block a user