Ask Your Question
0

attach volume get exception when instance_uuid is Invalid,but the status of volume is still attaching

asked 2013-06-04 21:19:57 -0500

sxmatch gravatar image

hi, I use the latest code of Grizzly, and first creat a volume by using cinder client "cinder create 3 --display-name volumeTest".

Then attach this volume with invaild instance uuid like "123" (sending the attach request to cinder directly),cinder throw an exception like this :

"{"badRequest": {"message": "Expected a uuid but received %(uuid).\nTraceback (most recent call last):\n\n File \"/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/amqp.py\", line 430, in processdata\n rval = self.proxy.dispatch(ctxt, version, method, *args)\n\n File \"/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/dispatcher.py\", line 133, in dispatch\n return getattr(proxyobj, method)(ctxt, *kwargs)\n\n File \"/usr/lib/python2.7/dist-packages/cinder/volume/manager.py\", line 575, in attachvolume\n return doattach()\n\n File \"/usr/lib/python2.7/dist-packages/cinder/openstack/common/lockutils.py\", line 228, in inner\n retval = f(args, *kwargs)\n\n File \"/usr/lib/python2.7/dist-packages/cinder/volume/manager.py\", line 558, in doattach\n raise exception.InvalidUUID(uuid=instanceuuid)\n\nInvalidUUID: Expected a uuid but received %(uuid).\n", "code": 400}}"

But the status of volume is still attaching:

root@controllerUbG183:~# cinder list

+--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+ | ID | Status | Display Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+

| 553b70d4-2d00-4911-861a-22ed1a78b7d0 | in-use | None | 2 | None | false | 82be03fe-fcd2-417e-a118-f1f0184a3071 |

| 73356c5b-3780-48df-8260-fad9b0aff0bb | attaching | volumeTest | 3 | None | false | |

| 7da7e619-3565-4aa2-9034-5f64e8d1fcad | in-use | None | 2 | None | false | 2416218a-95e4-4c9a-a01b-5fc5d565b9f4 |

| a123540c-3a2e-4a42-92c2-c9c70130f5e4 | in-use | None | 2 | None | false | 5c59b3e7-9b3e-4007-8abf-692c19d39e67 |

| b979490d-fb1a-4a89-b34f-ca9fe9b794f8 | in-use | None | 3 | None | false | 1327aaee-4dea-4ef5-85a4-b6e391fa9a59 |

+--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+

I found the code in manager.py , line 544:

self.db.volume_update(context, volume_id,
                                   {"instance_uuid": instance_uuid,
                                    "status": "attaching"})

            # TODO(vish): refactor this into a more general "reserve"
             # TODO(sleepsonthefloor): Is this 'elevated' appropriate?
  if not uuidutils.is_uuid_like(instance_uuid):
       raise exception.InvalidUUID(uuid=instance_uuid)

"uuidutils.isuuidlike" should be at the front of "db.volume_update" , isn't?

edit retag flag offensive close merge delete

1 answer

Sort by » oldest newest most voted
0

answered 2013-06-18 17:45:41 -0500

jgriffith gravatar image

You're correct, this is a bug. We should either be checking the UUID prior to the db update as you suggest, or do an update on the status when the uuid_like error is encountered. I've filed a bug [1], thanks!!

[1] https://bugs.launchpad.net/cinder/+bug/1192370

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

Stats

Asked: 2013-06-04 21:19:57 -0500

Seen: 115 times

Last updated: Jun 18 '13