configuration options from the [DEFAULT] section are not applied to multiple backends

[Jay Bryant]

It is expected that volume configurations options like 'volume_clear' that are set under the [DEFAULT] section will be inherited by multiple backends if the option is not set for the backend. Currently, however, the setting from the [DEFAULT] section is ignored and not set for multiple backends.

[Eric Harney (eharney)]

To me this seems like a big usability win for configuration unless we know of any reason to not do it. (I can't think of any.)

I've encountered multiple cases where people assume this will happen and don't get the right options into each backend section.

[John Griffith (john-griffith)]

I think this is fine, just so we make sure that anything can be over-ridden in the driver section. I had suggested at the summit a slightly different approach, something like driver groupings where the common config options would go under a specified section and a driver section could have an entry indicating that it inherits settings from that group.

something like:

[DRIVER_GROUP_ONE]
volume_driver = cinder.volume.driver.lvm
setting_foo = fiz
setting_baz = biz

[lvm-a]
group_member = DRIVER_GROUP_ONE
volume_group = vg-1

[lvm-b]
group_member = DRIVER_GROUP_ONE
volume_group = vg-2

The result is that lvm-a and lvm-b inherit the conf settings from the group_member setting. I don't know if this is better or worse. We should mess around with some use cases and decide what works best and is most flexible and yet condenses the config file.

[Jay Bryant (jsbryant)]

John, as I mentioned in IRC. I think this would be acceptable as well. Would there be a way to get an example like this into the default cinder.conf.sample file then? I think the important thing is that we have something explicit so that it is clear that backends are not going to inherit volume settings from the [DEFAULT] section. That is not clear currently.

Thoughts Eric?

[Matt Riedemann (mriedem)]

I'm going to ask around the infra/qa teams if they know about this and are setting it for their test runs because it looks like after fixing the problem in our CI we had substantially faster runs on some of the tempest volume tests like test_volumes_get, test_volume_types, and test_volumes_snapshots*. Looks like it made test_volumes_actions actually take longer.

[Matt Riedemann (mriedem)]

Looks like it would also impact devstack:

https://github.com/openstack-dev/devstack/blob/master/lib/cinder#L271

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/60694

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/60694
Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=7103a84e3900502648e81bd4313b777f2da63f92
Submitter: Jenkins
Branch: master

commit 7103a84e3900502648e81bd4313b777f2da63f92
Author: Matt Riedemann <email address hidden>
Date: Sat Dec 7 13:53:33 2013 -0800

    Workaround Cinder "wishlist" bug 1255593 for multi-backend volume_clear

    Cinder currently only applies the volume_clear setting from the DEFAULT
    section of cinder.conf if you're using a single backend.

    The Cinder team has determined this is a 'wishlist' item to propagate
    volume_clear to each backend, but it does impact usability and
    performance.

    To improve the performance of running Tempest with multi-backends in the
    gate, workaround the bug in devstack.

    Related-Bug: #1255593

    Change-Id: Ia0ff5422f53eeda9a3ac4336eefec3b9bdea6da2