Description of problem: volume cloning seems to fail when using qpid if some metadata is passed, see the following: # cinder create --metadata 'Type=Test' --source-volid d1ce1fc3-10fe-475f-9dc4-51261d04c323 1 ERROR: The server has either erred or is incapable of performing the requested operation. interestingly, this does not seem to happen when a new (non clone) volume is created Version-Release number of selected component (if applicable): openstack-cinder-2013.1.3-2.el6ost
cinder api.log reports some rather long traceback: InternalError: Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/qpid/messaging/driver.py", line 511, in dispatch self.engine.dispatch() File "/usr/lib/python2.6/site-packages/qpid/messaging/driver.py", line 815, in dispatch self.process(ssn) File "/usr/lib/python2.6/site-packages/qpid/messaging/driver.py", line 1050, in process self.send(snd, msg) File "/usr/lib/python2.6/site-packages/qpid/messaging/driver.py", line 1261, in send body = enc(msg.content) File "/usr/lib/python2.6/site-packages/qpid/messaging/message.py", line 28, in encode sc.write_primitive(type, x) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 73, in write_primitive getattr(self, "write_%s" % type.NAME)(v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 257, in write_map sc.write(string.joinfields(map(self._write_map_elem, m.keys(), m.values()), "")) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 250, in _write_map_elem sc.write_primitive(type, v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 73, in write_primitive getattr(self, "write_%s" % type.NAME)(v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 257, in write_map sc.write(string.joinfields(map(self._write_map_elem, m.keys(), m.values()), "")) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 250, in _write_map_elem sc.write_primitive(type, v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 73, in write_primitive getattr(self, "write_%s" % type.NAME)(v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 257, in write_map sc.write(string.joinfields(map(self._write_map_elem, m.keys(), m.values()), "")) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 250, in _write_map_elem sc.write_primitive(type, v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 73, in write_primitive getattr(self, "write_%s" % type.NAME)(v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 257, in write_map sc.write(string.joinfields(map(self._write_map_elem, m.keys(), m.values()), "")) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 250, in _write_map_elem sc.write_primitive(type, v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 73, in write_primitive getattr(self, "write_%s" % type.NAME)(v) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 300, in write_list type = self.encoding(o) File "/usr/lib/python2.6/site-packages/qpid/codec010.py", line 59, in encoding raise CodecException("no encoding for %r" % obj) CodecException: no encoding for <cinder.db.sqlalchemy.models.VolumeMetadata object at 0x458e610>
What's happening here is that jsonutils.to_primitive is not being called when source_volid is present. The diference is that source_volid skips the scheduler by calling rpcapi.cast directly. While the schedulare_rpcapi serializes volume's specs correctly, the direct cast executed when source_volid is passed doesn't. https://github.com/openstack/cinder/blob/stable/grizzly/cinder/volume/api.py#L260 This doesn't seem to happen in Havana, though. Most of the code involved in the volume creation was re-factored as part of the task flow blueprint, which most have fixed this issue.
After some more digging, I think the proposed patch should also go into master, although I couldn't replicated the bug there.
Also fixed in openstack-cinder-2013.1.4-1.el6ost via rebase.
Auto adding >= MODIFIED bugs to beta
verified using: openstack-cinder-2013.2-3.el6ost.noarch
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. http://rhn.redhat.com/errata/RHEA-2013-1859.html