So it may be difficult to reproduce the exact issue that Gabriel reported without knowing more about the openstack configuration (eg. regions, etc.).
However, I think this is missing the point, which is that the [nova] section is indeed missing and not configurable from juju for cinder.conf (and absolutely appears to be what is causing the bug). I'm not sure how we want this section to be configurable though. There are a lot of options:
So I tested with cinder-lvm, which using an iSCSI backend, and couldn't reproduce the issue. I then dug into the code and discovered that cinder appears to try to autodetect the keystone auth parameters if it doesn't find data in the [nova] section. (ref. code here: https:/ /opendev. org/openstack/ cinder/ src/commit/ 85387cae8b3641d 6d193c6550edbfb 0de1d8384e/ cinder/ compute/ nova.py# L98-L106 ).
So it may be difficult to reproduce the exact issue that Gabriel reported without knowing more about the openstack configuration (eg. regions, etc.).
However, I think this is missing the point, which is that the [nova] section is indeed missing and not configurable from juju for cinder.conf (and absolutely appears to be what is causing the bug). I'm not sure how we want this section to be configurable though. There are a lot of options:
[nova] compute/ nova.py
# locally declared in cinder:
region_name =
interface =
token_auth_url =
# declared in keystoneauth1: loading/ session. py
cafile =
certfile =
keyfile =
insecure =
timeout =
collect-timing =
split-loggers =
# declared in keystoneauth1: loading/ conf.py
auth_type =
auth_section =
---
Which do we want to expose as-is to the charm config, vs exposing a higher level config option, vs other methods?