Comment 0 for bug 1879578

When the 'cinder_img_volume_type' image property is on an image, a volume created from that image is supposed to use the specified volume_type (unless a different volume_type is specified in the volume-create request). Currently, all such create request result in a volume of the default volume_type (either operator configured, or __DEFAULT__).

This is a regression from Change I4da0c13b5b3f8174a30b8557f968d6b9e641b091 in Train.

It happens here at the REST API layer:
[0] https://opendev.org/openstack/cinder/src/commit/85e60732e21ee30937d43d8b77295e4525e1c8fc/cinder/api/v3/volumes.py#L324-L328
(that's from v3, but the same code is in v2)

The change was part of an effort to eliminate untyped volumes in Cinder. The problem is that it sets a volume_type too soon (probably so that the volume_type element in the API response wouldn't be null. But as a result, it bypasses the selection code in the cinder-volume service [1], which would infer the volume_type based on source volume type, snapshot volume type, or image volume type. So basically, unless a user explicitly sets a volume_type in the original API request, that user is going to wind up with the default type.

I think the way to fix this is to (roughly) move the code from [0] into [1]. We could just document that the volume_type can be null in the API response while a volume is still building.

Change I4da0c13b5b3f8174a30b8557f968d6b9e641b091, however, touched a *lot* of files, so there may be some dependencies on the volume_type being set early that I'm not seeing at first glance.

[1] https://opendev.org/openstack/cinder/src/commit/85e60732e21ee30937d43d8b77295e4525e1c8fc/cinder/volume/flows/api/create_volume.py#L356-L371