dedicated option to specify default_volume_type via charm

[Nobuto Murata]

At this moment, default_volume_type cannot be set to cinder.conf through the charm. The default type is useful when there are multiple storage backends connected to Cinder and when there is a preferred backend over the other by admins.

Let's say there are two storage backends, one with cheaper / slower storage, the other is more expensive / faster storage. When one doesn't issue an API with VOLUME_TYPE like the following command, then the backend will be chosen randomly.
$ openstack volume create --type VOLUME_TYPE --size 1 my-volume

The behavior may not be desirable for admins and they may want to set the default storage backend in this case slower storage unless faster and more expensive storage is explicitly requested through API.

Another way of implementing this is to leverage a new scheme introduced in Train, and set a property into the __DEFAULT__ type.
https://specs.openstack.org/openstack/cinder-specs/specs/train/untyped-volumes-to-default-volume-type.html

$ openstack volume type show __DEFAULT__
+--------------------+--------------------------------------+
| Field | Value |
+--------------------+--------------------------------------+
| access_project_ids | None |
| description | Default Volume Type |
| id | 1bf252f4-8279-4fcf-a007-285a630dcc5b |
| is_public | True |
| name | __DEFAULT__ |
| properties | volume_backend_name='Ceph' |
| qos_specs_id | None |
+--------------------+--------------------------------------+

However, it's not as flexible as cinder.conf because it doesn't allow to be changed later on.

$ openstack volume type set __DEFAULT__ --property volume_backend_name=NEW_DEFAULT_FROM_NOW_ON
Failed to set volume type property: Volume Type is currently in use. (HTTP 400) (Request-ID: req-f9730450-5ace-4ff0-afc1-3a33bd677734)
Command Failed: One or more of the operations failed

So the config in cinder.conf is still valid and usable like it's mentioned in the commit log of the new scheme.
"Admins can override the default type in cinder.conf"
https://opendev.org/openstack/cinder/commit/a550ade303c839abc285d6926dc02a15b5c73ff0

Please note that, there is a regression in upstream for Train and later releases, but it doesn't affect the scope of the work in charm.
https://bugs.launchpad.net/cinder/+bug/1879578

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/737288

[Nobuto Murata (nobuto)]

The option can be set via "config-flags" in the charm. So the importance would be not so high.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/737288
Committed: https://git.openstack.org/cgit/openstack/charm-cinder/commit/?id=12193d2bc20c354923cea27e12ace89d4fde9aaf
Submitter: Zuul
Branch: master

commit 12193d2bc20c354923cea27e12ace89d4fde9aaf
Author: Nobuto Murata <email address hidden>
Date: Mon Jun 22 22:56:45 2020 +0900

    Allow specifying default_volume_type

    It's useful when multiple storage backends to be connected to Cinder.
    The corresponding volume type must be created after a deployment via API
    to take effect, e.g., `openstack volume type create VOLUME_TYPE
    --property volume_backend_name=BACKEND_NAME`

    Please note that there is a regression in upstream as LP: #1879578, so
    it doesn't work for Train or later releases until the issue gets fixed.

    The other way to have the similar effect is to edit the definition of
    __DEFAULT__ volume type via API (available for Train or later releases).
    Howevers it's not as flexible as the option in cinder.conf since it
    doesn't allow any modification unless all of the volumes with the
    __DEFAULT__ type get deleted.

    Change-Id: I031a6bf2a066bb9d3157e545bb9df782a76551f3
    Closes-Bug: #1884548