When using local.conf in multinode envs not everything is going to be
defined in all places. Eventually we probably want to make it so we
have a host role for these sections or something. But for now warn
instead of die when we can't find a config var.
Change-Id: I6959099373f035fbfe9e540a44e4c52b8e7c95c0
Closes-Bug: #2000824
The current coding fails to process local.conf like
the following. Note: This example is taken from a
real use case. [1]
[[post-config|$NEUTRON_CONF]]
[qos]
notification_drivers = midonet
[[post-config|$NEUTRON_CONF]]
[quotas]
# x10 of default quotas (at the time of writing)
quota_network=100
quota_subnet=100
quota_port=500
quota_router=100
quota_floatingip=500
quota_security_group=100
quota_security_group_rule=1000
[1] https://review.openstack.org/#/c/400627/
Closes-Bug: #1583214
Change-Id: Ie571b5fa5a33d9ed09f30ba7c7724b958ce17616
XenServer install with devstack doesn't support local.conf, this fix
is to add support for using local.conf and backward-compatibility of
localrc
Change-Id: Ie494e01f8f1ecb8720e14392ef3f12d5a5a01dcd
Closes-Bug: #1528520
I noticed this when debugging some grenade issues failures.
An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.
We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.
When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).
The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.
The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.
Some files had already discovered this. In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste. This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.
Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
If local.conf specifies a config file addition in the following way...
[[post-config|$MY_CONF_FILE]]
[xyz]
foo=bar
...and $MY_CONF_FILE points to a file whose directory is not writable by
the user running the script, then stack.sh aborts with the following
obscure message:
2015-09-01 08:20:08.113 | touch: setting times of '/': Permission denied
This patch modifies inc/meta-config to provide a useful error message,
such as:
2015-09-01 08:20:08.114 | could not create config file / ($MY_CONF_FILE)
This patch also modifies inc/meta-config so that it provides an error
message if $MY_CONF_FILE is empty (instead of silently ignoring this local.conf
statement):
2015-09-01 09:38:53.406 | bogus config file specification: $MY_CONF_FILE
is undefined
Change-Id: I9b78407420318548561012a8672762bc7fdd6db6
Closes-Bug: 1490881
Change If132a94e53545d9134859aa508da7b9819ede2f8 introduced a small
regression; it added an "inidelete" which looks in the config file to
delete rows.
However, at least for the test-case, the config file isn't created
yet. The end result is that the test fails but we don't notice.
2015-04-17 00:55:03.169 | merge_config_file test-multiline: sed: can't read test-multiline.conf: No such file or directory
2015-04-17 00:55:03.195 | OK
So fix this up by creating the config-file if it isn't there.
Also, add "-e" to the test file so we catch things like this in the
future.
Change-Id: I43a4ecc247f19cccf51d5931dfb687adbd23d6b1
* config/INI functions from functions-common to to inc/ini-config
* local.conf meta-config functions from lib/config to inc/meta-config
Change-Id: I00fab724075a693529273878875cfd292d00b18a
