Regarding Nova's inability to delete the Cinder volume for creating virtual machines (version Y)

[sam]

When creating a virtual machine in the dashboard, create a volume and choose to delete the virtual machine while also deleting the volume. When deleting the virtual machine, there is no normal uninstallation of the volume and the volume is not deleted.

The relevant error logs are shown in the image, but the openstack CLI can delete its volume. The specific commands are as follows.

CLI：

source /etc/keystone/admin-openrc.sh (Verify password file)
openstack volume set --detached　191e555c-3947-4928-be46-9f09e2190877（volumeID）
openstack volume delete 191e555c-3947-4928-be46-9f09e2190877（volumeID）

It seems that Nova is unable to interact with the Cinder API to delete(or detached) commands, but I am not very professional. I don't know if it's a bug?

此错误跟踪器适用于文档错误，请使用以下内容作为模板，并根据需要删除或添加字段。将 [ ] 转换为 [x] 以复选框：

- [ ] 此文档以这种方式不准确：______
- [ ] 这是一个文档添加请求。
- [ ] 我对文档有一个修复程序，我可以粘贴到下面，包括示例：输入和输出。

如果您有故障排除或支持问题，请使用以下资源：

- 邮件列表：https://lists.openstack.org
 - IRC：电讯局的「开放栈」频道

-----------------------------------
发布： 25.2.2.dev1 在 2019-10-08 11：20：05
SHA： fd0d336ab5be71917ef9bd94dda51774a697eca8
来源： https://opendev.org/openstack/nova/src/doc/source/install/index.rst
网址： https://docs.openstack.org/nova/yoga/install/

[sam (sam22926)]

In the dashboard, you can see in the volume options bar that the volume has been mounted to the virtual machine, but the virtual machine has been deleted. In this case, it is not correct. In theory, the volume can be deleted when deleting the virtual machine.

[sam (sam22926)]

Note that I have seen similar bug patch files, but they are invalid.
URL:
  BUG page
  https://bugs.launchpad.net/nova/+bug/2016173

  Page for patching files
  https://review.opendev.org/c/openstack/nova/+/880399

Is not working!!!

[Uggla (rene-ribaud)]

Hello Sam,

Thanks for reporting this bug !
Yes I can confirm it is a bug, I managed to reproduce it on devstack and current release.

To my mind, the volume should remain, but in a proper status (available and detached).

By the way it seems that the boot volume is handled properly, but not supplemental attached volume.

Here is the reproducer on my side:
stack@openstack:~/nova$ openstack server list
+--------------------------------------+------------+---------+-----------------------------------------------------------------------+--------------------------+--------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+------------+---------+-----------------------------------------------------------------------+--------------------------+--------+
| 2360e339-5147-44b4-a4ac-87261b70abf2 | bug_detach | ACTIVE | private=10.0.0.4, fd4a:c3be:3d9c:0:f816:3eff:fe1c:5f7b | N/A (booted from volume) | ds512M |
| efe970a5-b446-4d3e-869e-8221701e259c | demo | SHUTOFF | private=10.0.0.29, 172.24.4.211, fd4a:c3be:3d9c:0:f816:3eff:fef4:4b74 | N/A (booted from volume) | ds512M |
+--------------------------------------+------------+---------+-----------------------------------------------------------------------+--------------------------+--------+
stack@openstack:~/nova$ openstack volume create --size 1 myvolume
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2023-11-07T14:14:39.510165 |
| description | None |
| encrypted | False |
| id | cc6ed45a-90c5-4735-8048-1f4d20b6cf08 |
| migration_status | None |
| multiattach | False |
| name | myvolume |
| properties | |
| replication_status | None |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| type | ceph |
| updated_at | None |
| user_id | 73800863dd9e4c799406254c518355ed |
+---------------------+--------------------------------------+

stack@openstack:~/nova$ openstack volume list
+--------------------------------------+----------+-----------+------+-------------------------------------+
| ID ...

[sam (sam22926)]

Hi, Uggla
Thank you for your reply!!!
My openstack is already working properly.
It has been confirmed that the issue is caused by the security reinforcement of CVS 2023 2088 and additional configuration is required to eliminate the issue.
https://nvd.nist.gov/vuln/detail/CVE-2023-2088
https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html
Simply follow the second method, theoretically it is possible to delete the volume while deleting the virtual machine normally

[sean mooney (sean-k-mooney)]

reviewing the steps rene performed and the initial bug description this work flow is not supported

nova has never supported attaching a volume to a guest via the cidner API
and detaching it has been explicitly blocked due to the cve exposures

so for nova i belive this is invalid.

cinder likely should prevent normal user form creating attachments for a nova instance with the same mitigation as the detach case.

creating a volume attachment for a nova instance should require a service token with the service role
just as delete does.

[sean mooney (sean-k-mooney)]

to be clear

stack@openstack:~/nova$ openstack --os-volume-api-version 3.27 volume attachment create myvolume bug_detach
+-------------+--------------------------------------+
| Field | Value |
+-------------+--------------------------------------+
| ID | 16c04c0c-0ad4-4223-a953-e7ae8bbad545 |
| Volume ID | cc6ed45a-90c5-4735-8048-1f4d20b6cf08 |
| Instance ID | 2360e339-5147-44b4-a4ac-87261b70abf2 |
| Status | reserved |
| Attach Mode | null |
| Attached At | |
| Detached At | |
| Properties | |
+-------------+--------------------------------------+

should require a service token