There is a wide variety of tracing options through the various shell
scripts. Some use "set -eux", others explicity set xtrace and others
do nothing. There is a "-x" option to bin/disk-image-create but it
doesn't flow down to the many scripts it calls.
This adds a global integer variable set by disk-image-create
DIB_DEBUG_TRACE. All scripts have a stanza added to detect this and
turn on tracing. Any other tracing methods are rolled into this. So
the standard header is
---
if [ "${DIB_DEBUG_TRACE:-0}" -gt 0 ]; then
set -x
fi
set -eu
set -o pipefail
---
Multiple -x options can be specified to dib-create-image, which
increases the value of DIB_DEBUG_TRACE. If script authors feel their
script should only trace at higher levels, they should modify the
"-gt" value. If they feel it should trace by default, they can modify
the default value also.
Changes to pachset 16 : scripts which currently trace themselves by
default have retained this behaviour with DIB_DEBUG_TRACE defaulting
to "1". This was done by running [1] on patch set 15. See the thread
beginning at [2]
dib-lint is also updated to look for the variable being matched.
[1] https://gist.github.com/ianw/71bbda9e6acc74ccd0fd
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/051575.html
Change-Id: I6c5a962260741dcf6f89da9a33b96372a719b7b0
As with the previous similar changes, this is intended to catch
problems as they happen instead of ignoring them and continuing on
to potentially fail later. Setting this on all existing scripts
will allow us to enforce use via Jenkins.
Change-Id: Iad2d490c86dceab148ea9ab08f457c49a5d5352e
Fixes problems found by set -eu and pipefail, including:
-Many unset variables
-Commands that can fail under normal circumstances, which breaks
with set -e. This change swallows those expected errors to allow
our existing error code to handle them.
-The dkms element was not finding Fedora kernel versions correctly.
This may be an issue for other distros too, but since Fedora was
working fine without this functionality I only changed it to print
a warning message rather than failing the build when it happens.
-The ramdisk init script will not be set -eu because if it fails
the result is a kernel panic, which can be tricky to debug.
However, in testing with set -e a few failing commands were found
and have been fixed in this patch.
Change-Id: I44cf98dfc80cfcaec54b88cc83be80a3dbf2cec3
We were applying proxy settings after apt-get install runs are done
in the Ubuntu element, which made it ineffective. Secondly, we were
not applying no_proxy settings to apt, which caused it to fail in
corporate settings. More explicit control may be facilitated in future
but local-config is a DTRT tool, and so we should help it DTRT.
I think I've correctly setup Zypper for this, and I have no idea
how to make the same improvement for Yum (and also Yum currently
doesn't set HTTPS proxies, which may lead to similar reports there).
Change-Id: Idbb9781d64d44b717ea22a25429383fa45d84148
Per bug 1182648 we were not setting the mode and as a result couldn't
log in, defeating the purpose of having a local-config element :).
Change-Id: I4114b9536392f1517eac8f4bbe6f4b60ce1186a1
Currently, the local-config and stackuser elements
are intertwined. local-config installs an authorized_key
for stackuser, if the stackuser element is in use.
This change does two things:
- add authorized_key for root from local-config element,
regardeless of whether stackuser element is in use.
- install key for stack user from stackuser element,
only if local-config element is in use.
Change-Id: I0d07b61404119ea0650c5c0fb98d6786adcf3ca9
Fix whitespace error in local-config/install.d/61-http-proxy that prevents
no-proxy being written.
Change-Id: Ie2511bb5b2504c42ff59ec277cd91bf92b56da59
Previously, only http_proxy was copied into the local-config image.
We now preserve both http_proxy and https_proxy settings.
Change-Id: I4de2712f2772fb7d07b228cecdc0c8ec6f3df567
Co-authored-by: Chris Krelle <nobodycam@gmail.com>
Flavour is overloaded in openstack due to it being used by nova. Element
seems to have the same feeling of combinability without using a term already
in active use in the openstack community.
Change-Id: Ia4c028d4062a8f69c66665821c94dd4bcdf06031
