Mixed cloud configs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
os-client-config |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Because os-client-config initializes with the OS_ env vars [1] you can easily wind up with a mixed cloud configs.
Take for example these env vars
export OS_AUTH_URL=https:/
export OS_REGION_NAME=IAD
export OS_TENANT_NAME=xxx
export OS_TENANT_ID=xxx
export OS_USERNAME=xxx
export OS_PASSWORD=xxx
export OS_API_KEY=xxx
With this clouds.yaml
clouds:
test_cloud:
auth:
auth_url: http://
username: demo
password: devstack
project_name: demo
region_name: RegionOne
And you do
test_cloud = os_client_
You wind up with a test_cloud.config of
{
'auth_type': 'password',
'username': 'xxx',
'api_key': 'xxx',
'password': 'xxx',
'auth_url': 'https:/
'region_name': 'RegionOne',
'auth': {
'username': 'demo',
'project_name': 'demo',
'password': 'devstack',
'auth_url': 'http://
}
'compute_
'identity_
'image_
'network_
'object_
'volume_
}
Where you can see we have mixed cloud configs. This is confusing at best. At worst the region_name has been overridden and is now invalid for the values outside of the 'auth' key.
It's tempting to suggest that env vars should be loaded after any clouds.yaml and be used to override values in clouds.yaml but that way lies madness. You'll never be able to guarantee that one env var should override a particular value for all cloud configs.
My preference would be to see the env vars define their own independent and separate cloud config. They would in no way be mixed into any other cloud config. They could be accessed by a special name or even have an env var that sets the name for the cloud config. e.g.
export OS_CLIENT_
test_cloud = os_client_
[1] http://
Changed in os-client-config: | |
milestone: | none → 1.7.4 |
status: | Fix Committed → Fix Released |
Reviewed: https:/ /review. openstack. org/172652 /git.openstack. org/cgit/ openstack/ os-client- config/ commit/ ?id=7e682d3bf09 7a006ec43c16ecc 96664bf4b29294
Committed: https:/
Submitter: Jenkins
Branch: master
commit 7e682d3bf097a00 6ec43c16ecc9666 4bf4b29294
Author: Monty Taylor <email address hidden>
Date: Sat Apr 11 08:27:05 2015 -0400
Put env vars into their own cloud config
The semantics around mixing environment variables and config file values
are confusing at best and no reasonable usecase has been expressed as to
why doing so is desirable.
Move the logic around environment variable processing to always provide
an "envvars" cloud if any envvars are set. The cloud will only exist in
the presence of OS_ env vars.
get_one_cloud() will default to returning the envvars cloud if it
exists.
Change-Id: I6c3a54997c3278 feedfdf93cc4d1e 74b6235700a
Closes-Bug: #1439927