Description of problem: While testing Cinder volume backup and restore I faced the following error ~~~~~~~~~~~~~~~~ (openstack) volume backup restore vol1_backup3 vol1 'VolumeBackupsRestore' object is not iterable ~~~~~~~~~~~~~~~~ Version-Release number of selected component (if applicable): RHOS10 latest version python-openstackclient-3.2.1-1.el7ost.noarch python-cinderclient-1.9.0-6.el7ost.noarch puppet-cinder-9.5.0-1.el7ost.noarch How reproducible: Steps to Reproduce: 1. Create volume 2. backup volume 3. run the following command to recover volume (openstack) volume backup restore vol1_backup3 vol1 Actual results: 'VolumeBackupsRestore' object is not iterable Expected results: command successfully ended with no error Additional info: The restore was successfully done No error while running equivalent command from cinder backup-restore
Try working around this by using: "cinder backup-restore --volume <uuid> <backup_uuid>"
This is a DFG:Storage bug, moving the needinfo to the DFG team catalyst for now. Looking at the upstream Launchpad it looks like a patch for this was merged in 3.18.0, which will be in OSP15. Note that there is also a workaround provided in comment 5.
Sofia, can you verify if this is a clone of https://bugzilla.redhat.com/show_bug.cgi?id=1689342 and if so assign to yourself?
Yes, it looks like a clone of bz1689342. Thanks
Can't verify (yet) P2 2020-01-15.3 produced a pre-fixed in of: python-openstackclient-lang-3.14.3-4.el7ost < python-openstackclient-3.14.3-5.el7ost
Verified on: python-openstackclient-lang-3.14.3-5.el7ost.noarch 1. Create volume: (overcloud) [stack@undercloud-0 ~]$ cinder create 1 --image cirros --name source +--------------------------------+--------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2020-02-11T09:43:57.000000 | | description | None | | encrypted | False | | id | ef2ce5a1-9562-48ef-91b2-1e4a133f542c | | metadata | {} | | migration_status | None | | multiattach | False | | name | source | | os-vol-host-attr:host | controller-0@3par#SSD_r5 | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 2cd01b0fe6c644a48cbfa6da5a03d25b | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | creating | | updated_at | 2020-02-11T09:43:57.000000 | | user_id | b8c1ccd7e02c4f22ad8929f1cb5fcaba | | volume_type | tripleo | +--------------------------------+--------------------------------------+ Volume is available: | ef2ce5a1-9562-48ef-91b2-1e4a133f542c | available | source | 1 | tripleo | true | | 2. backup volume (overcloud) [stack@undercloud-0 ~]$ cinder backup-create ef2ce5a1-9562-48ef-91b2-1e4a133f542c --name backup1 +-----------+--------------------------------------+ | Property | Value | +-----------+--------------------------------------+ | id | c5ffd40a-b563-47ac-8570-feca4f08899c | | name | backup1 | | volume_id | ef2ce5a1-9562-48ef-91b2-1e4a133f542c | +-----------+--------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ cinder backup-list +--------------------------------------+--------------------------------------+-----------+---------+------+--------------+---------------+ | ID | Volume ID | Status | Name | Size | Object Count | Container | +--------------------------------------+--------------------------------------+-----------+---------+------+--------------+---------------+ | c5ffd40a-b563-47ac-8570-feca4f08899c | ef2ce5a1-9562-48ef-91b2-1e4a133f542c | available | backup1 | 1 | 22 | volumebackups | +--------------------------------------+--------------------------------------+-----------+---------+------+--------------+---------------+ 3. run the following command to recover volume (overcloud) [stack@undercloud-0 ~]$ openstack volume backup restore backup1 source +-------------+--------------------------------------+ | Field | Value | +-------------+--------------------------------------+ | backup_id | c5ffd40a-b563-47ac-8570-feca4f08899c | | volume_id | ef2ce5a1-9562-48ef-91b2-1e4a133f542c | | volume_name | source | +-------------+--------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ cinder list +--------------------------------------+------------------+------------+------+-------------+----------+-------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+------------------+------------+------+-------------+----------+-------------+ | ef2ce5a1-9562-48ef-91b2-1e4a133f542c | restoring-backup | source | 1 | tripleo | true | | +--------------------------------------+------------------+------------+------+-------------+----------+-------------+ Backup completed volume returned to available state: | ef2ce5a1-9562-48ef-91b2-1e4a133f542c | available | source | 1 | tripleo | true | | Verified openstack client backup/restore worked as excepted without errors.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0769