Commit graph

8 commits

Author SHA1 Message Date
Ian Wienand
97c01e48ed Move elements & lib relative to diskimage_builder package
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
2016-11-01 17:27:41 -07:00
Abel Lopez
570ecf16a5 Set and export DIB_RELEASE for centos7
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
2015-08-04 08:35:20 -07:00
Ian Wienand
b183e024ba Work around yum/dnf differences
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
2015-06-24 09:20:45 +10:00
Ian Wienand
36b59c001c Standarise tracing for scripts
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
2015-02-12 10:41:32 +11:00
Monty Taylor
9cd5068854 Remove use of sudo from yum pre and post elements
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
2014-11-28 11:01:40 -05:00
Ben Nemec
16be6d7ce0 set -u and -o pipefail everywhere
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
2014-05-06 15:51:07 -05:00
Ralf Haferkamp
ba5aa8725e Fix $TARGET_ROOT usage in yum element
Fix the test for $TARGET_ROOT in root.d/50-yum-cache.

Don't use $TARGET_ROOT in pre-install, it's only set for "root" and "cleanup".

Change-Id: I048364ea08ef503a4466f3494f18f72ebf99b5c2
2013-12-10 17:56:42 +01:00
James Slagle
c9a6aef9f4 Add yum element.
The yum element provides for specific customizations
for yum based distros.  The included customization is
a yum cache mounted outside of the chroot so that yum
downloaded packages are reused on subsequent image builds.

Change-Id: I6833c9fdbc83cb09debec6a789082e105c917800
2013-08-14 18:26:51 -04:00