Description of problem:
The enable_backends parameter shouldn't be left blank, it should have a name of a backend (LVM, NFS or Ceph) assigned to it with it create a new section, for an example: [LVM]
that holds all the driver parameters and settings.
Or the staypuft should comment out the enable_backends.
(the first option is preferred, for a single backend as well)
Version-Release number of selected component (if applicable):
There's no value assigned to the enabled_backend parameter
1. set the used driver type (LVM/NFS/Ceph) with an addition section in the cinder.conf file
2. comment out the parameter
This should be handled in the quickstack modules, not in staypuft directly.
(In reply to Yogev Rabl from comment #0)
> Description of problem:
> The enable_backends parameter shouldn't be left blank, it should have a name
> of a backend (LVM, NFS or Ceph) assigned to it with it create a new section,
> for an example: [LVM]
> that holds all the driver parameters and settings.
> Or the staypuft should comment out the enable_backends.
> (the first option is preferred, for a single backend as well)
> Version-Release number of selected component (if applicable):
> How reproducible:
> Actual results:
> There's no value assigned to the enabled_backend parameter
> Expected results:
> 1. set the used driver type (LVM/NFS/Ceph) with an addition section in the
> cinder.conf file
This sounds like you have altered the cinder.conf directly? If so, there is no way for puppet to pick up on that. If not, what did you set in the staypuft UI for cinder configuration? Also, is this a non-HA setup? Nova Networking or Neutron?
> 2. comment out the parameter
> Additional info:
What you're describing (use of enabled_backends and creating backend sections) happens when multiple_backends is set to true. When multiple_backends is false, cinder allows configuring the backend directly in the config file without having to create the sections. (Instead of using the sections, volume_driver parameter in cinder.conf is used to specify the backend driver. I think this is the original way before multiple backends were introduced). Here's an example how the config contents might look in more detail:
Is there something not working when using the volume_driver approach instead of enabled_backends?
In theory we could use the multi-backend approach even for single backend and get rid of the multiple_backends variable, but due to the way Openstack Puppet Modules handle config files it seems a bit safer not to do so. (Leftover backend sections can appear when switching multi-backend configurations. It shouldn't have a tangible impact though.)
1. I haven't changed the cinder.conf manually, just reviewed it.
2. I set the Cinder back end as Ceph and that's it, I didn't changed the advanced settings.
3. It is a non-HA neutron setup.
The Cinder can work with this configuration, the reason I opened this bug is because I see open variables in the config files as a practice we should avoid.
To the second point, I've suggested the multiple backend approach as default because it will organize the cinder.conf which will make it easier to manage.
Refocusing engineering efforts on OSP7-Manager.
Closing this BZ due to low priority and no customer cases attached.