Missing validation for bootstrap_address in restore_values
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
StarlingX |
Fix Released
|
Low
|
Raphael Lima |
Bug Description
Brief Description
-----------------
When providing the bootstrap_address in restore_values, there's no validation if the provided value have a valid format. Right now, the address is added in inventory exactly as provided and will fail when running the Ansible playbook.
Severity
--------
Minor: System/Feature is usable with minor issue
Steps to Reproduce
------------------
Perform subcloud backup (dcmanager subcloud-backup create --subcloud <subcloud_name> --sysadmin-password <password>)
Create restore_values.yml with a bootstrap_address with invalid format (like 10.10.10.22.22)
Perform subcloud restore with the file (dcmanager subcloud-backup restore --subcloud <subcloud_name> --restore-values <restore_
Expected Behavior
------------------
The dcmanager api rejects the request before calling the playbook.
Actual Behavior
----------------
The playbook starts executing.
Reproducibility
---------------
100% reproducible
System Configuration
-------
DC with at least 1 subcloud
Last Pass
---------
NA
Timestamp/Logs
--------------
Created restore_values.yml:
bootstrap_address:
subcloud2: 10.10.20.22.22
Ansible log for the subcloud:
2023-11-15-22:28:14 Executing playbook command: ['ansible-
Wednesday 15 November 2023 22:28:14 +0000 (0:00:00.021) 0:00:00.021 ****
skipping: [subcloud2]TASK [common/
Wednesday 15 November 2023 22:28:14 +0000 (0:00:00.023) 0:00:00.045 ****
ok: [subcloud2]TASK [common/
Wednesday 15 November 2023 22:28:14 +0000 (0:00:00.026) 0:00:00.071 ****
[DEPRECATION WARNING]: Distribution debian 11 on host subcloud2 should use
/usr/bin/python3, but is using /usr/bin/python for backward compatibility with
prior Ansible releases. A future Ansible release will default to using the
discovered platform python for this host. See https:/
2.10/reference_
feature will be removed in version 2.12. Deprecation warnings can be disabled
by setting deprecation_
changed: [subcloud2]TASK [common/
Wednesday 15 November 2023 22:28:14 +0000 (0:00:00.188) 0:00:00.260 ****
skipping: [subcloud2]TASK [common/prepare-env : stat] *******
Wednesday 15 November 2023 22:28:14 +0000 (0:00:00.047) 0:00:00.307 ****
ok: [subcloud2] => (item=/
ok: [subcloud2] => (item=/
ok: [subcloud2] => (item=/
ok: [subcloud2] => (item=/
Wednesday 15 November 2023 22:28:15 +0000 (0:00:00.559) 0:00:00.866 ****
skipping: [subcloud2] => (item={'changed': False, 'stat': {'exists': False}, 'invocation': {'module_args': {'path': '/root/
skipping: [subcloud2] => (item={'changed': False, 'stat': {'exists': False}, 'invocation': {'module_args': {'path': '/root/
skipping: [subcloud2] => (item={'changed': False, 'stat': {'exists': False}, 'invocation': {'module_args': {'path': '/root/site.yml', 'follow': False, 'get_md5': False, 'get_checksum': True, 'get_mime': True, 'get_attributes': True, 'checksum_
skipping: [subcloud2] => (item={'changed': False, 'stat': {'exists': False}, 'invocation': {'module_args': {'path': '/root/
Wednesday 15 November 2023 22:28:15 +0000 (0:00:00.025) 0:00:00.891 ****
ok: [subcloud2]TASK [common/prepare-env : Format the ansible host if it is an IP address] *****
Wednesday 15 November 2023 22:28:15 +0000 (0:00:00.015) 0:00:00.907 ****
skipping: [subcloud2]TASK [common/prepare-env : Check connectivity] *******
Wednesday 15 November 2023 22:28:15 +0000 (0:00:00.024) 0:00:00.931 ****
fatal: [subcloud2]: FAILED! => changed=false
elapsed: 10
msg: Timeout when waiting for 10.10.20.22.22:22
PLAY RECAP *******
subcloud2 : ok=4 changed=1 unreachable=0 failed=1 skipped=4 rescued=0 ignored=0Wednesday 15 November 2023 22:28:25 +0000 (0:00:10.340) 0:00:11.271 ****
=======
common/prepare-env : Check connectivity -------
common/prepare-env : stat -------
common/
common/
common/
common/prepare-env : include_vars -------
common/prepare-env : Format the ansible host if it is an IP address ----- 0.02s
common/
common/prepare-env : Set SSH port -------
Test Activity
-------------
Developer Testing
Workaround
----------
NA
information type: | Public → Public Security |
information type: | Public Security → Public |
Changed in starlingx: | |
status: | New → In Progress |
assignee: | nobody → Raphael Lima (r-lima) |
Changed in starlingx: | |
importance: | Undecided → Low |
tags: | added: stx.9.0 stx.distcloud stx.update |
Reviewed: https:/ /review. opendev. org/c/starlingx /distcloud/ +/901911 /opendev. org/starlingx/ distcloud/ commit/ 4141cc8b160d120 8d6aa3a6717963f 4a588a92d1
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit 4141cc8b160d120 8d6aa3a6717963f 4a588a92d1
Author: rlima <email address hidden>
Date: Mon Nov 27 09:07:23 2023 -0300
Missing validation for bootstrap_address in restore_values
When providing the bootstrap_address in restore_values, there wasn't
a validation to ensure the provided value had a valid format. Right
now, the address is added in inventory exactly as provided and will
fail when running the Ansible playbook.
This review includes a validation step that evaluates the IP address
value and raises an exception in case it isn't valid, aborting the
process for the invalid subcloud.
Test plan:
All test cases were performed after a subcloud was deployed and
had its backup taken.
Success cases:
- PASS: Run 'dcmanager subcloud-backup restore' for a subcloud
using the restore_values.yml file with a valid IP address. The
subcloud was successfully restored.
- PASS: Run 'dcmanager subcloud-backup restore' for a subcloud
group using the restore_values.yml file with a valid IP address
for a subcloud and an invalid one for another. The subcloud
with the valid IP address was successfully restored.
Failure cases:
- PASS: Run 'dcmanager subcloud-backup restore' for a subcloud
using the restore_values.yml file with an invalid IP address.
An error appears in the console stating that the IP address
is invalid for the specified subcloud.
- PASS: Run 'dcmanager subcloud-backup restore' for a subcloud
group using the restore_values.yml file with a valid IP address
for a subcloud and an invalid one for another. The subcloud with
the invalid IP address wasn't restored.
Closes-Bug: 2044551
Change-Id: Ie9f937db1185aa 242112efba17741 d97707181f3
Signed-off-by: rlima <email address hidden>