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
For whatever reason, RHEL identifies itself with DISTRO "rhel" for 6
and "rhel7" for 7, but centos just uses "centos" and DIB_RELEASE. So
this was wrong and installing EPEL6 on centos7.
But we can simplify it completely for centos because that comes with
the epel-release package already included.
Change-Id: I2b8f5d30b850fef46b4a5ba32a917abcbf25932c
Fedora has changed the location of epel, shorting the link
from 'download.fedoraproject.org' to 'dl.fedoraproject.org'.
This change updates the epel mirror to prevent it from timing
out.
Change-Id: I87090282a2f5f757495daec6ad14123b436b1aa0
download.fedoraproject.org uses dns round robin and occasionally
hits a bad server. Using DIB_EPEL_MIRROR when finding the
epel-release package will allow us to avoid it e.g. in ci.
Change-Id: I756223b3e669532476663c05e79c238449b8a0db
epel-release 7.2 has been superseded by 7.5, so update accordingly.
this time, detect the available epel-release package from the repo
instead of hardcoding version number which will break build each
time the version number gets bumped up.
Change-Id: I29c73355a85112840b57f93b39a9eeda421875e6
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
instack runs this script on a system where epel has already been
installed, which causes the yum command to fail. Only installing
the epel-release rpm when it isn't already present addresses the
issue.
Change-Id: Ia179d7c7ed69ea5f785b5dcd16394c7663a145cc
EPEL 7 was released September 30. The beta release rpm was removed
from the repo and was replaced with the final release rpm.
Change-Id: I103a2f7abd7563869b9e39ccc1fbb3cfbd9ff6ae
This patch adds a new EPEL element for use with EL-based distros
in accordance with the official docs[1]. This patch also
modifies the rhel7 element to not use the hard-coded repo file.
[1] https://fedoraproject.org/wiki/EPEL
Change-Id: Ib2fa24b2d519837271a0e213a2dc5a012cc31f3c
