`cinder manage` creates volume with status `error`

[Sergei Chipiga]

MOS #427
1 node: controller
1 node: compute, cinder

CLI steps:

root@node-1:~# cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 2e48c311-0b2d-4788-b7bf-80016f45baa5 | available | test | 1 | volumes_lvm | false | |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
root@node-1:~# cinder show 2e48c311-0b2d-4788-b7bf-80016f45baa5
+--------------------------------+--------------------------------------------------+
| Property | Value |
+--------------------------------+--------------------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2016-06-03T09:11:41.000000 |
| description | |
| encrypted | False |
| id | 2e48c311-0b2d-4788-b7bf-80016f45baa5 |
| metadata | {} |
| migration_status | None |
| multiattach | False |
| name | test |
| os-vol-host-attr:host | node-2.test.domain.local@LVM-backend#LVM-backend |
| os-vol-mig-status-attr:migstat | None |
| os-vol-mig-status-attr:name_id | None |
| os-vol-tenant-attr:tenant_id | 0fb1968d97f344f1bbef0a992a5a9074 |
| replication_status | disabled |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | available |
| updated_at | 2016-06-03T09:11:43.000000 |
| user_id | b3676f1fb69e4c75b5eb6ff6177c7419 |
| volume_type | volumes_lvm |
+--------------------------------+--------------------------------------------------+
root@node-1:~# cinder manage node-2.test.domain.local@LVM-backend#LVM-backend 2e48c311-0b2d-4788-b7bf-80016f45baa5
+--------------------------------+--------------------------------------------------+
| Property | Value |
+--------------------------------+--------------------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2016-06-03T11:23:54.000000 |
| description | None |
| encrypted | False |
| id | e6137771-c7d5-4614-b16a-2633aefe9419 |
| metadata | {} |
| migration_status | None |
| multiattach | False |
| name | None |
| os-vol-host-attr:host | node-2.test.domain.local@LVM-backend#LVM-backend |
| os-vol-mig-status-attr:migstat | None |
| os-vol-mig-status-attr:name_id | None |
| os-vol-tenant-attr:tenant_id | 0fb1968d97f344f1bbef0a992a5a9074 |
| replication_status | None |
| size | 0 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| updated_at | None |
| user_id | b3676f1fb69e4c75b5eb6ff6177c7419 |
| volume_type | None |
+--------------------------------+--------------------------------------------------+
root@node-1:~# cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 2e48c311-0b2d-4788-b7bf-80016f45baa5 | available | test | 1 | volumes_lvm | false | |
| e6137771-c7d5-4614-b16a-2633aefe9419 | error | - | 0 | - | false | |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+

The same situation with volume manage via horizon UI.

In some documentation, as I can found, `cinder manage` creates available volume:
http://netapp.github.io/openstack-deploy-ops-guide/juno/content/cinder.examples.cinder_cli.html

[Bug Checker Bot (bug-checker)]

(This check performed automatically)
Please, make sure that bug description contains the following sections filled in with the appropriate data related to the bug you are describing:

actual result

version

expected result

For more detailed information on the contents of each of the listed sections see https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Here_is_how_you_file_a_bug

[Yuriy Nesenenko (ynesenenko)]

This is the wrong way of using the manage command. The second argument for manage command should be a name for existing volume on storage not an id in DB (2e48c311-0b2d-4788-b7bf-80016f45baa5) as above.

[Sergei Chipiga (schipiga)]

using name as second argument, I have the same problem:

root@node-1:~# cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 2e48c311-0b2d-4788-b7bf-80016f45baa5 | available | test | 1 | volumes_lvm | false | |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
root@node-1:~# cinder show 2e48c311-0b2d-4788-b7bf-80016f45baa5
+--------------------------------+--------------------------------------------------+
| Property | Value |
+--------------------------------+--------------------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2016-06-03T09:11:41.000000 |
| description | |
| encrypted | False |
| id | 2e48c311-0b2d-4788-b7bf-80016f45baa5 |
| metadata | {} |
| migration_status | None |
| multiattach | False |
| name | test |
| os-vol-host-attr:host | node-2.test.domain.local@LVM-backend#LVM-backend |
| os-vol-mig-status-attr:migstat | None |
| os-vol-mig-status-attr:name_id | None |
| os-vol-tenant-attr:tenant_id | 0fb1968d97f344f1bbef0a992a5a9074 |
| replication_status | disabled |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | available |
| updated_at | 2016-06-03T09:11:43.000000 |
| user_id | b3676f1fb69e4c75b5eb6ff6177c7419 |
| volume_type | volumes_lvm |
+--------------------------------+--------------------------------------------------+
root@node-1:~# cinder manage node-2.test.domain.local@LVM-backend#LVM-backend test
+------------------------------...

[Yuriy Nesenenko (ynesenenko)]

The name for existing volume on storage ('volume-2e48c311-0b2d-4788-b7bf-80016f45baa5') and the name in DB (test OR id='2e48c311-0b2d-4788-b7bf-80016f45baa5' in the above example) are, as they say in Odessa, two big differences.

[Yuriy Nesenenko (ynesenenko)]

The name for existing volume on STORAGE ('volume-2e48c311-0b2d-4788-b7bf-80016f45baa5') and the name in DB (test OR id='2e48c311-0b2d-4788-b7bf-80016f45baa5' in the above example) are, as they say in Odessa, two big differences.

[Sergei Chipiga (schipiga)]

Yuriy, according your words, should I execute `cinder manage node-2.test.domain.local@LVM-backend#LVM-backend volume-2e48c311-0b2d-4788-b7bf-80016f45baa5` ?

but something is wrong again:

root@node-1:~# cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 2e48c311-0b2d-4788-b7bf-80016f45baa5 | available | test | 1 | volumes_lvm | false | |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
root@node-1:~# cinder show 2e48c311-0b2d-4788-b7bf-80016f45baa5
+--------------------------------+--------------------------------------------------+
| Property | Value |
+--------------------------------+--------------------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2016-06-03T09:11:41.000000 |
| description | |
| encrypted | False |
| id | 2e48c311-0b2d-4788-b7bf-80016f45baa5 |
| metadata | {} |
| migration_status | None |
| multiattach | False |
| name | test |
| os-vol-host-attr:host | node-2.test.domain.local@LVM-backend#LVM-backend |
| os-vol-mig-status-attr:migstat | None |
| os-vol-mig-status-attr:name_id | None |
| os-vol-tenant-attr:tenant_id | 0fb1968d97f344f1bbef0a992a5a9074 |
| replication_status | disabled |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | available |
| updated_at | 2016-06-03T09:11:43.000000 |
| user_id | b3676f1fb69e4c75b5eb6ff6177c7419 |
| volume_type | volumes_lvm |
+--------------------------------+----------------------------------...

[Yuriy Nesenenko (ynesenenko)]

First of all, you should unmanage a volume otherwise you'll get what you've got (in the cinder-volume log "Volume is already managed.") To do it just run: "$ cinder unmanage 2e48c311-0b2d-4788-b7bf-80016f45baa5". To look at volumes' names on storage you can use such commands: "sudo lvs" for LVM; "sudo rbd ls -l -p volumes" for Ceph. And then run: "$ cinder manage <host> <volume_name>", where <volume_name> is the name on STORAGE (that is, the output of the above commands).

[Sergei Chipiga (schipiga)]

With these steps, it works properly. But I suppose, that when I try to manage already managed volume it should return error "Volume is managed already" or to manage volume with invalid id (or name) it should return error "Volume identifier is not recognized". But it creates volume with error status. It looks like unpredictable behavior and bug, doesn't it?

[Sergei Chipiga (schipiga)]

As I understood after consultation with Yuriy Nesenenko and Ivan Kolodyazhnhy, that's normal behavior for such architecture. So no questions now. Closing bug.

[Yuriy Nesenenko (ynesenenko)]

The attempt of manage the already managed volume is an invalid case. After implementing specs https://github.com/openstack/cinder-specs/blob/master/specs/newton/summarymessage.rst a user will be able to recieve "Error message" for such actions.