Attempt to import duplicate backup record deletes existing record
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
High
|
Brian Rosmaita |
Bug Description
If I have an existing backup record in Cinder:
$ openstack volume backup list
+----
| ID | Name | Description | Status | Size |
+----
| fa571535-
+----
And I attempt to import a duplicate record:
$ openstack volume backup record export -f value fa571535-
$ openstack volume backup record import $(cat record.txt)
The import will fail as expected:
Invalid backup: Backup already exists in database. (HTTP 400) (Request-ID: req-c3a84538-
But it will unexpectedly delete the existing backup:
$ openstack volume backup list
<empty response>
description: | updated |
Changed in cinder: | |
importance: | Undecided → Low |
tags: | added: backup-service openstack-cli record |
Changed in cinder: | |
status: | New → Confirmed |
importance: | Low → Medium |
Changed in cinder: | |
status: | Confirmed → Triaged |
tags: | added: low-hanging-fruit |
Changed in cinder: | |
importance: | Medium → High |
tags: | removed: record |
Changed in cinder: | |
assignee: | nobody → Brian Rosmaita (brian-rosmaita) |
Here's the code:
https:/ /opendev. org/openstack/ cinder/ src/commit/ 41e315d63a3ba38 2ba6e95f55b2776 0ca4e7a592/ cinder/ backup/ api.py
We check for this condition in a double nested try loop (line 576), raise an InvalidBackup excption, and then catch it ourselves at line 586 and proceed to destroy the backup.
Looks like the reason for the nested try is so that we can roll back a quota reservation made earlier at line 541. Would probably be better to check for whether the backup already exists (and raise) *before* we make the reservation.