34 lines
1.6 KiB
YAML
34 lines
1.6 KiB
YAML
---
|
|
fixes:
|
|
- |
|
|
`Bug #1879578 <https://bugs.launchpad.net/cinder/+bug/1879578>`_:
|
|
A regression in the Train release caused Cinder to assign the default
|
|
volume type too aggressively when a volume type was not specified in
|
|
a volume-create request. As a result, some alternative methods of
|
|
specifying the volume type were ignored and the default type (either
|
|
configured by the operator or the system default) would be assigned.
|
|
|
|
This release restores the intended behavior, which is described as
|
|
follows:
|
|
|
|
If a ``volume_type`` is not specified when a volume is created, Cinder
|
|
tries to infer the volume type from other information in the
|
|
volume-create request:
|
|
|
|
* if a ``source_volid`` is supplied in the request, the volume type
|
|
is inferred from the source volume's volume type
|
|
* if a ``snapshot_id`` is supplied in the request, the volume type
|
|
is inferred from the volume type associated with the snapshot
|
|
* if an ``imageRef`` is supplied in the request, and the image has
|
|
a ``cinder_img_volume_type`` image property, the volume type is
|
|
inferred from the value of that image property
|
|
|
|
Otherwise, the volume type is the default volume type configured by
|
|
the operator, and if no volume type is so configured, the volume type
|
|
is the system default volume type, namely, ``__DEFAULT__``.
|
|
|
|
When a volume type is specified explicitly in a volume-create call, Cinder
|
|
will use the specified type. If the specified type cannot be assigned due
|
|
to a conflict with other parameters in the volume-create call, however, the
|
|
call will result in a 400 (Bad Request) response.
|