36b59c001c
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
|
||
|---|---|---|
| .. | ||
| environment.d | ||
| root.d | ||
| README.rst | ||
pip-cache
# Use a cache for pip
Using a download cache speeds up image builds.
Including this element in an image build causes $HOME/.cache/image-create/pip to be bind mounted as /tmp/pip inside the image build chroot. The $PIP_DOWNLOAD_CACHE environment variable is then defined as /tmp/pip, which causes pip to cache all downloads to the defined location.
Note that pip and its use of $PIP_DOWNLOAD_CACHE is not concurrency safe. Running multiple instances of diskimage-builder concurrently can cause issues. Therefore, it is advised to only have one instance of diskimage-builder that includes the pip-cache element running at a time.
The pip concurrency issue is being tracked upstream at https://github.com/pypa/pip/issues/1141