Как удалить “неудаляемый” диск в openstack

Бывают такие ситуации, когда диск openstack невозможно удалить штатными средствами.
Например, некоторые действия с диском не отображены в базе данных MySQL в результате каких-то сбоев.

Рассмотрим все на конкретном примере. Проблемный диск: volume_id=522b22a3-155b-4dd8-8b5a-c158e1410145

Запишем идентификатор диска в переменную VOLID.
VOLID=‘522b22a3-155b-4dd8-8b5a-c158e1410145’

Attachments

Проверить и удалить “мертвые” attachments 

select * from volume_attachment where volume_id=$VOLID;
delete from volume_attachment where volume_id=$VOLID;

Snapshots

Проверить и удалить снэпшоты 

select * from snapshots where volume_id=$VOLID;
delete from snapshots where volume_id=$VOLID;

Transfers

Проверить, нет ли незавершенной миграции диска 

select * from transfers where volume_id=$VOLID;
Если есть - удалить: 
delete from transfers where volume_id=$VOLID;

Удаление

Удалить наконец-то проблемный диск: 

openstack volume delete --force $VOLID

Если будет сообщение такого типа: 

Invalid volume: Volume  must not be migrating, attached, belong to a consistency group or have snapshots. (HTTP 400) (Request-ID: req-3fc7dc02-ee95-444c-b4a0-f68e5c67aa8d)
Значит еще надо проверять, нет ли этого диска в очередях на миграцию и в группах целостности.

В таблицах backups, cgsnapshots, consistencygroups, driver_initiator_data encryption, image_volume_cache_entries, iscsi_targets, snapshot_metadata, в нашем случае нет записей. Поэтому это не может повлияить на возможность удаления диска.

Проверяем все параметры нашего диска 

cinder show $VOLID

+--------------------------------+----------------------------------------------+
|            Property            |                    Value                     |
+--------------------------------+----------------------------------------------+
|          attachments           |                      []                      |
|       availability_zone        |                     nova                     |
|            bootable            |                    false                     |
|      consistencygroup_id       |                     None                     |
|           created_at           |          2018-05-29T12:44:23.000000          |
|          description           |                                              |
|           encrypted            |                    False                     |
|               id               |     522b22a3-155b-4dd8-8b5a-c158e1410145     |
|            metadata            | {'readonly': 'False', 'attached_mode': 'rw'} |
|        migration_status        |                     None                     |
|          multiattach           |                    False                     |
|              name              |                     test                     |
|     os-vol-host-attr:host      |           dc-stor-01@object#object           |
| os-vol-mig-status-attr:migstat |                     None                     |
| os-vol-mig-status-attr:name_id |                     None                     |
|  os-vol-tenant-attr:tenant_id  |       e3cc5d1e0569481e91e936546a2dbe1c       |
|       replication_status       |                   disabled                   |
|              size              |                     100                      |
|          snapshot_id           |                     None                     |
|          source_volid          |                     None                     |
|             status             |                  available                   |
|           updated_at           |          2019-01-31T07:55:18.000000          |
|            user_id             |       12ac19dd84804572a97c0bb6221371eb       |
|          volume_type           |                    object                    |
+--------------------------------+----------------------------------------------+

Metadata

В данном случае диск все равно не хотел удаляться, т.к. у него в метаданных осталась запись (‘attached_mode’: ‘rw’).

Это можно посмотреть в таблице volume_admin_metadata 

mysql> select * from volume_admin_metadata where volume_id=$VOLID;
+---------------------+------------+---------------------+---------+-----+--------------------------------------+---------------+-------+
| created_at          | updated_at | deleted_at          | deleted | id  | volume_id                            | key           | value |
+---------------------+------------+---------------------+---------+-----+--------------------------------------+---------------+-------+
| 2018-05-29 12:45:16 | NULL       | NULL                |       0 | 937 | 522b22a3-155b-4dd8-8b5a-c158e1410145 | readonly      | False |
| 2018-05-29 12:45:17 | NULL       | 2018-05-29 13:21:12 |       1 | 940 | 522b22a3-155b-4dd8-8b5a-c158e1410145 | attached_mode | rw    |
| 2018-05-29 13:29:30 | NULL       | NULL                |       0 | 949 | 522b22a3-155b-4dd8-8b5a-c158e1410145 | attached_mode | rw    |
+---------------------+------------+---------------------+---------+-----+--------------------------------------+---------------+-------+
3 rows in set (0.01 sec)

Удаляем ненужные записи по ключу: value=’rw’

delete from volume_admin_metadata where volume_id=$VOLID and value='rw';

Status

В моем конкретном случае и это не помогло. Причина была в том, что диск находился в статусе “attached”.

mysql> select id,attach_status from volumes where id=$VOLID;
+--------------------------------------+---------------+
| id                                   | attach_status |
+--------------------------------------+---------------+
| 522b22a3-155b-4dd8-8b5a-c158e1410145 | attached      |
+--------------------------------------+---------------+
1 row in set (0.00 sec)
Смотрим, какие статусы бывают:

mysql> select distinct attach_status from volumes;
+---------------+
| attach_status |
+---------------+
| detached      |
| attached      |
| none          |
+---------------+
3 rows in set (0.00 sec)

Сбрасываем статус подключения в none 

update volumes set attach_status='none' where id=$VOLID;

Наконец-то получилось удалить наш злополучный диск командой: 

openstack volume delete --force 522b22a3-155b-4dd8-8b5a-c158e1410145
Проверяем, что диск действительно удалился: 
dog vdi list volume-522b22a3-155b-4dd8-8b5a-c158e1410145
Получаем “пустой” список – значит все успешно: 
Name        Id    Size    Used  Shared    Creation time   VDI id  Copies  Tag

Крайний вариант

Что делать, если ничего не помогло?

На крайний вариант, если все вышеприведенные приемы на помогли, удаляем вручную запись о диске с таблице volumes и во всех связанных таблицах, в которых есть $VOLID.

После этого вручную удаляем диск в хранилище: 

dog vdi delete volume-$VOLID

31.01.2019