create_backup xml interface does not honour the "name" argument

Bug #1270589 reported by Giulio Fidente
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Cinder
Invalid
Medium
John Griffith

Bug Description

A new test (in tempest) for the backup API fails against the XML interface only, which apparently is not honouring (or maybe showing) the "name" argument passed in the POST request:

2014-01-18 23:53:43,963 Large body (10866) md5 summary: f2b62af496b561fbf715c409cd4530eb
2014-01-18 23:53:43,964 Request: POST http://127.0.0.1:8776/v1/04d5d01de38d40ecb7694d91ace3cda3/backups
2014-01-18 23:53:43,964 Request Headers: {'Content-Type': 'application/xml', 'Accept': 'application/xml', 'X-Auth-Token': '<Token omitted>'}
2014-01-18 23:53:43,965 Request Body: <?xml version="1.0" encoding="UTF-8"?>
<backup xmlns="http://docs.openstack.org/compute/api/v1.1" container="" description="" name="Backup-tempest-1807029271" volume_id="26f2d737-d481-47da-ad88-c7777bf52d1d"/>
2014-01-18 23:53:44,319 Response Status: 202
2014-01-18 23:53:44,320 Nova request id: req-5f1c9f45-a1a4-45b1-b348-34083a3e8fa0
2014-01-18 23:53:44,320 Response Headers: {'content-length': '170', 'date': 'Sat, 18 Jan 2014 23:53:44 GMT', 'content-type': 'application/xml', 'connection': 'close'}
2014-01-18 23:53:44,320 Response Body: <?xml version='1.0' encoding='UTF-8'?>
<backup xmlns:backups="http://docs.openstack.org/volume/ext/backups/api/v1" name="None" id="fb5d82e8-c973-4810-96d7-d5c2fb74869d"/>

JSON interface works well:

2014-01-18 18:02:14,484 Request: POST http://127.0.0.1:8776/v1/f36aafdf03944f5ba98e238d610cf4f0/backups
2014-01-18 18:02:14,485 Request Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': '<Token omitted>'}
2014-01-18 18:02:14,485 Request Body: {"backup": {"name": "Backup-tempest-1473599217", "volume_id": "73d79718-b196-4a3f-974e-48ec9565c541"}}
2014-01-18 18:02:14,780 Response Status: 202
2014-01-18 18:02:14,780 Nova request id: req-c4e5dd4f-0718-4c4b-800f-95149c2bb2ff
2014-01-18 18:02:14,780 Response Headers: {'content-length': '369', 'date': 'Sat, 18 Jan 2014 18:02:14 GMT', 'content-type': 'application/json', 'connection': 'close'}
2014-01-18 18:02:14,780 Response Body: {"backup": {"id": "cb4be5c6-94d9-4a26-b260-a1ab30d4bc27", "links": [{"href": "http://127.0.0.1:8776/v1/f36aafdf03944f5ba98e238d610cf4f0/backups/cb4be5c6-94d9-4a26-b260-a1ab30d4bc27", "rel": "self"}, {"href": "http://127.0.0.1:8776/f36aafdf03944f5ba98e238d610cf4f0/backups/cb4be5c6-94d9-4a26-b260-a1ab30d4bc27", "rel": "bookmark"}], "name": "Backup-tempest-1473599217"}}

Tags: backup
description: updated
description: updated
Changed in cinder:
assignee: nobody → Leandro Ignacio Costantino (leandro-i-costantino)
Revision history for this message
Leandro Ignacio Costantino (leandro-i-costantino) wrote :

It seems that 'name' field is not taken in account on XML Deserializer but display_name instead.
Which should be the right one?

something like this in cinder/api/contrib/backups.py should work:

@@ -90,7 +90,7 @@ class CreateDeserializer(wsgi.MetadataXMLDeserializer):
         backup = {}
         backup_node = self.find_first_child_named(node, 'backup')

- attributes = ['container', 'display_name',
+ attributes = ['container', 'display_name', 'name',
                       'display_description', 'volume_id']

         for attr in attributes:

Changed in cinder:
assignee: Leandro Ignacio Costantino (leandro-i-costantino) → nobody
Revision history for this message
John Griffith (john-griffith) wrote :

Honestly I'd like to drop support for using name altogether and just require UUID, but that's beside the point :)

Thanks for logging this and tracking it down.

Changed in cinder:
status: New → Triaged
importance: Undecided → Medium
Changed in cinder:
assignee: nobody → John Griffith (john-griffith)
tags: added: backup
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote : Bug Cleanup

Closing stale bug. If this is still an issue please reopen.

Changed in cinder:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.