I've been doing some more research on the bug. The issue is that class OpenStackConfig from [1] is initialized twice, at [2] and [3], with OS_CLOUD_NAME passed as an environment variable.
The first time it is initialized, the configuration gets inside self.cloud_config, and since the environment variable is still around, the second time it fails in [4].
We could either remove the check in [4] or make the OpenStackConfig init code resilient to multiple initializations. I'm not familiar enough with the codebase to decide which option is better.
I've been doing some more research on the bug. The issue is that class OpenStackConfig from [1] is initialized twice, at [2] and [3], with OS_CLOUD_NAME passed as an environment variable.
The first time it is initialized, the configuration gets inside self.cloud_config, and since the environment variable is still around, the second time it fails in [4].
We could either remove the check in [4] or make the OpenStackConfig init code resilient to multiple initializations. I'm not familiar enough with the codebase to decide which option is better.
[1] - https:/ /github. com/openstack/ os-client- config/ blob/990cfa3ce2 4d0a92c7578b52a e1fea02d69f7e87 /os_client_ config/ config. py#L177 /github. com/openstack/ python- openstackclient /blob/ef99f4446 28282d06feae045 14bd2a6328d87b9 3/openstackclie nt/shell. py#L137 /github. com/openstack/ python- openstackclient /blob/ef99f4446 28282d06feae045 14bd2a6328d87b9 3/openstackclie nt/shell. py#L146- L152 /github. com/openstack/ os-client- config/ blob/990cfa3ce2 4d0a92c7578b52a e1fea02d69f7e87 /os_client_ config/ config. py#L250- L256
[2] - https:/
[3] - https:/
[4] - https:/