Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions playbooks/dcn.yml
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,15 @@
ansible.builtin.include_role:
name: ci_dcn_site

- name: Verify cinder backups across AZs
when: dcn_test_cinder_backups | default('true')
cifmw.general.ci_script:
output_dir: "{{ cifmw_basedir }}/artifacts"
extra_args:
ANSIBLE_LOG_PATH: "{{ cifmw_basedir }}/logs/cinder_backups_test.log"
script: |
ansible-playbook -i {{ inventory_file }} {{ cifmw_repo }}/hooks/playbooks/cinder_backups.yaml

- name: The map for az0 contains all AZ backends
ansible.builtin.set_fact:
az_to_group_map:
Expand Down
23 changes: 18 additions & 5 deletions roles/ci_dcn_site/templates/service-values.yaml.j2
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,26 @@ data:
cinderAPI:
replicas: 3
cinderBackup:
replicas: 3
replicas: 0
customServiceConfig: |
[DEFAULT]
backup_driver = cinder.backup.drivers.ceph.CephBackupDriver
backup_ceph_conf = /etc/ceph/az0.conf
backup_ceph_pool = backups
backup_ceph_user = openstack
# Not implemented in this example
cinderBackups:
{% for _ceph in _ceph_vars_list %}
{% if _ceph.cifmw_ceph_client_cluster != _az_to_scaledown %}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you're deploying cinderBackup on two AZs so that you don't have to scale it down?

Is the test code running on the same two AZs.

I think that's OK. You could come back and scaling down cinder backup in a future patch.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The template has a conditional check if _ceph.cifmw_ceph_client_cluster != _az_to_scaledown to determine which AZs are to be included in the generated cinderBackups configuration.

During the default deploy loop (without scaledown), _az_to_scaledown is set empty (roles/ci_dcn_site/defaults/main.yml:29), so all the AZs in _ceph_vars_list pass the check and are included in the cinderBackups rendered.

For the optional scaledown task, user provides cifmw_ci_dcn_site_scaledown_az, and _az_to_scaledown is set to this value (playbooks/dcn.yml:85), causing the template to exclude this specific AZ from rendered configuration for scaledown task, triggering controlplane update to remove the backup service of that AZ.

It would be good to test the backup creation and restoration post scaledown task. I believe you were suggesting the same. :)

{{ _ceph.cifmw_ceph_client_cluster }}:
customServiceConfig: |
[DEFAULT]
storage_availability_zone = {{ _ceph.cifmw_ceph_client_cluster }}
backup_driver = cinder.backup.drivers.ceph.CephBackupDriver
backup_ceph_conf = /etc/ceph/{{ _ceph.cifmw_ceph_client_cluster }}.conf
backup_ceph_pool = backups
backup_ceph_user = openstack
networkAttachments:
- storage
replicas: 1
{% endif %}
{% endfor %}
cinderVolumes:
{% for _ceph in _ceph_vars_list %}
{% if _ceph.cifmw_ceph_client_cluster != _az_to_scaledown %}
Expand Down
Loading