Commit graph

7 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
Ben Nemec
6377c723aa Allow elements to add drivers to dracut
It is reasonable that elements may need to include additional
kernel modules in a dracut ramdisk.  This is done with the
--add-drivers option to dracut, but previously the value passed
was hard-coded.

This change allows an element to put a file containing its desired
drivers in a dracut-drivers.d directory, and the list there will
be added to the list of drivers added.  This functions in
essentially the same way as the binary-deps.d directory that
already exists for including additional executables in a ramdisk.

Change-Id: Ie892b908d36c175a469f7cde7dd803ad4b1942b6
2015-03-18 11:40:20 -05: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
Erwan Velu
75b34baa98 dracut-ramdisk: fix support for elements with ramdisk-install.d
Copy all of TMP_MOUNT_PATH into the ramdisk so that
ramdisk-install.d actions are respected.

Includes a workaround for a bug in Dracut that caused the copy
to fail.

Also moves init instead of copying it so we don't conflict with
the Dracut init.

Change-Id: Ia8d7b210369fe7eb7ab239cbdb7f96841104a35d
Closes-Bug: 1403121
2014-12-18 11:46:49 +01:00
Ben Nemec
0db6b9b401 Unset trap before dracut ramdisk build script exits
A similar change was needed in the normal ramdisk element as part
of ae928057bd to avoid running
cleanup immediately after the ramdisk build completes.

Change-Id: Ia96e2d8011b88ed96cc6727914c5a5d2dea59757
2014-10-23 20:02:08 -05:00
Ben Nemec
bb8126e887 Use binary-deps.d for dracut ramdisks
Instead of hard-coding a list of binaries to include in the dracut
ramdisk, use the existing binary-deps.d functionality to provide a
list.  This will allow other ramdisks (such as discovery) to add
the binaries they need.

Change-Id: Ib7ffa15e08db1cc45e93a8f2a5c01369772c93ff
2014-10-22 15:13:48 -05:00
Ben Nemec
eed30adc48 Enable dracut deploy ramdisks
The element builds dracut from source on Ubuntu because the
Ubuntu dracut package is broken and very old, so it can't be
installed properly and causes a number of other issues that
are fixed by using a newer version of Dracut.

This initial version should work in virtualized environments.
Further validation of its suitability for real baremetal
deployments will need to be done in the future, but this should
be sufficient to enable that work.

Regarding Dracut specifically, in order to limit the changes
needed in the existing scripts this element continues to use a
cut down version of the /init script that we were building for the
existing ramdisk.  However, instead of running it as pid 0 it is
run as a Dracut pre-mount hook.  This allows Dracut to set up all
of the hardware and system bits, while falling early enough in the
Dracut sequence to complete the deployment before Dracut would try
to boot off the hard disk.

bp tripleo-juno-dracut-ramdisks
Change-Id: I144c8993fe040169f440bd4f7a428fdbe3d745cf
2014-10-17 21:44:09 -05:00