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
With gerrit 2.8, and the new change screen, this will trigger syntax
highlighting in gerrit. Thus making reviewing code a lot nicer.
Change-Id: Id238748417ffab53e02d59413dba66f61e724383
This is the first step in supporting multiple Cinder backend types at
once. It initially converts the existing hard-coded multi-lvm support
to a new cinder_backends driver form. Eventually the cinder_plugins
will be converted to this form so they can be enabled more than just
one at a time using CINDER_ENABLED_BACKENDS.
The default configuration should be identical to the previous defaults,
including for both True and False values of CINDER_MULTI_LVM_BACKEND.
The existing cinder_plugins are expected to be removed when this is
complete. They should continue to work until they have been converted.
Add wait for c-api to ensure it is started before continuing.
Change-Id: I93b8ef32832269d730c76a6dc24ddb4f20c6d9df