Currently we have all our elements and library files in a top-level
directory and install them into
<root>/share/diskimage-builder/[elements|lib] (where root is either /
or the root of a virtualenv).
The problem with this is that editable/development installs (pip -e)
do *not* install data_files. Thus we have no canonical location to
look for elements -- leading to the various odd things we do such as a
whole bunch of guessing at the top of disk-image-create and having a
special test-loader in tests/test_elements.py so we can run python
unit tests on those elements that have it.
data_files is really the wrong thing to use for what are essentially
assets of the program. data_files install works well for things like
config-files, init.d files or dropping documentation files.
By moving the elements under the diskimage_builder package, we always
know where they are relative to where we import from. In fact,
pkg_resources has an api for this which we wrap in the new
diskimage_builder/paths.py helper [1].
We use this helper to find the correct path in the couple of places we
need to find the base-elements dir, and for the paths to import the
library shell functions.
Elements such as svc-map and pkg-map include python unit-tests, which
we do not need tests/test_elements.py to special-case load any more.
They just get found automatically by the normal subunit loader.
I have a follow-on change (I69ca3d26fede0506a6353c077c69f735c8d84d28)
to move disk-image-create to a regular python entry-point.
Unfortunately, this has to move to work with setuptools. You'd think
a symlink under diskimage_builder/[elements|lib] would work, but it
doesn't.
[1] this API handles stuff like getting files out of .zip archive
modules, which we don't do. Essentially for us it's returning
__file__.
Change-Id: I5e3e3c97f385b1a4ff2031a161a55b231895df5b
Make sure we reset the yum/dnf cache to /var/cache/${YUM}, not just
/var/cache/yum
This was resulting in the F22 fedora-minimal image being larger than
the base-image. Because F22 fedora-minimal does some installs with
dnf when bootstrapping the chroot before we set "cachedir=" to the
bind-mounted external cache, we have "/var/cache/dnf" created and and
populated with the package meta-data, etc.
When we globally point dnf to /var/cache/yum here, we effectively
orphan the /var/cache/dnf created in those first steps. dnf doesn't
care, but we end up with two copies of all the package metadata, etc
in "/var/cache/dnf" & "/var/cache/yum".
This also cleans up the sed a bit, by just replacing the lines.
Change-Id: Icc98fe30c34cb941aed4b987647ab67ac34af15a
The default value was set in the centos7 element, but not
exported, which caused issues in rpm-distro. Also changed
a test in rpm-distro to only check for DIB_RELEASE > 22
if it's fedora.
Closes-Bug: #1477172
Change-Id: Ib6f4227411c2e8f1965c3b78bc318512c59a7876
Some minor workarounds for Fedora >= 22 where dnf is the default
package manager. The changes are documented on the Fedora release
notes https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
Change-Id: I7d7d6f5d294980dcb217d6190a1efd9e0bbea9a6
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
sudo is not needed, since in-chroot elements are run in the context
of the root user. Furthermore, sudo in pre-install is problematic as
sudo may not have been installed yet (imagine a debootstrap build)
Change-Id: Ib5c7e176a90fe3b8fa9c3cd702d3d815df54f472
When using the yum element, we should reset the changes we've made to
/etc/yum.conf during post-install.d. Otherwise, this build time
configuration is propagated into booted instances.
Change-Id: I1eea586ca0fefe9bc0cf91fedefcbd141a536fa2
