It has always been a weird thing that dib is a python package, but
is totally driven by the disk-image-create script. It creates this
strange division that is hard to explain.
This moves disk-image-create to a regular python entry-point
Currently, this simply exec()s the original disk-image-create script.
However, we now have a (private) interface between disk-image-create
written in python and the driver shell script. Here's some things we
could do, for example:
* Argument parsing is generally nicer in Python, and then end result
is mostly just setting environment variables to flag different things
in the shell script. I could see us moving the argument-parsing into
diskimage_builder.disk_image_create:main() and just setting things in
os.environ before the exec()).
* I7092e1845942f249175933d67ab121188f3511fd sets IMAGE_ELEMENT_YAML in
disk-image-create by calling-back to element-info. We can just call
element_dependencies.find_all_elements() in here an export is to
os.environ before disk-image-create starts.
* remove need for ramdisk-image-create symlink by just exporting
IS_RAMDISK based on sys.argv[1] value
* you could even unit test some of this :)
Change-Id: I69ca3d26fede0506a6353c077c69f735c8d84d28
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
If element-info fails we do not detect it due to it being run in a
subshell. Whenever this happens it is a terminal error (theres no way we
can run without an expanded set of elements) so lets detect and fail
early.
Change-Id: Ibdeecf19bc2824982273ef5cda6d7b7b614e484e
The refresh operation must happen after the cache has been added in
order to ensure that whatever is in the cache is still relevant to
the current build and we are not using stale packages.
Change-Id: Iafd718e9738f85b8c235806c027665730f44d89b
Closes-Bug: 1589450
Load the vfat driver as a Pre Exec action for systemd before starting
ironic-python-agent in order to allow reading of parameters.txt file
required for the ironic-python-agent to find its configuration.
Change-Id: Ibf74dd1b2678ea76e0676711a7aa5ba6b88d5421
The directory openstack/common was used to keep codes from
oslo-incubator, we have retired oslo-incubator, so don't use
this directory any more
Change-Id: Icd13d32674b117626fbecdfdec2881463a87ad5d
diskimage-builder already uses PBR:-
setuptools.setup(
setup_requires=['pbr>=1.8'],
pbr=True)
This patch removes `MANIFEST.in` file as pbr generates a
sensible manifest from git files and some standard files
and it removes the need for an explicit `MANIFEST.in` file.
Change-Id: Iad8b724c1d1e0ef358606b13da4569d881ec740a
AFAICT this is no longer necessary. I've tested minimal and image
builds and they seem to work.
The original problem seems to be with installing the package in the
chroot, although it was never quite clear it ever affected the Red Hat
path.
This code is currently broken (see
I884cb1e78ad8c31d985f3fc94a58091b993edd7d). This is proposed as an
alternative to I74eed074494134334d5e49042bb5214bd0dd7339.
Related-Bug: #1627000
Change-Id: Iafe3611f4eec3c6357587a6cae6a30a261686ead
Currently, this is a noop, since diskimage-builder currently uses
tests/install_test_deps.sh to manage OS dependencies. The next patch
in the series, will complete the migration to bindep.
Change-Id: I3b599983106b87fec6a4b6348469ed037654810e
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We're getting double time-stamps in the console log of upstream jobs.
Move the logging of a prefix datestamp into a "-t" option to retain
the status quo prior to Id9ea5131f0026c292ca6453ba2c80fe12c47f808 (we
could, of course, do it the other way and turn if off in the jobs, but
since we didn't have it before...)
While poking, make the time-stamp consistent and always prefixed if -t
is turned on.
Also, it seems the parallel options got a bit of sync with what got
merged. Add "-j" documentation and remove unused "p" option.
Change-Id: Ic7c2ebeca3f9d5784cac59505b6e6181151f5805
Recommended packages are usually useful but we normally don't need
them in order to have a working system. As a result, avoid pulling
them in when doing a regular package installation or a distribution
update. Extra packages can be pulled in using the usual '-p' parameter
or from within the elements that actually need them. The results of
this change are quite significant, resulting to gains from a few dozen
of MBs up to a few hundred depending on the selected elements.
Change-Id: I5838829c631990c7a1f3b67548accd9a603fe20c
When debugging, this is very noisy for very little value. If we need
to specifically debug this script we can turn up the level.
Change-Id: Ie15f16397c37e718aa919853697cbf2c5c08503c
Because environment files are sourced into the current environment,
they shouldn't be setting global settings like tracing else they
affect every preceeding import. This is quite confusing when only
half your imports are traced in the logs, because it was either turned
on, or off, by a preceeding environment import.
There is a corresponding dib-run-parts change in
I29f7df1514aeb988222d1094e8269eddb485c2a0 that will greatly increase
debugability for environment files by deliberately logging what files
are sourced and consistently turning on tracing around their import.
This isn't strictly necessary (since dib-run-parts with the prior
change will just turn tracing off after import anyway) but it's a
decent cleanup for consistency. A bare-minimum dib-lint check is
added. Documentation is updated.
Change-Id: I10f68be0642835a04af7e5a2bc101502f61e5357
We are running into race conditions with glean, which ssh-keygen -A is
not handling properly. So, create a new script to first check if the
file exists, then use 'yes' to disable overwriting of existing files.
Change-Id: Ie82e1e3f832fcc8f32c7e1335c5f0ee16d36f9a8
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Theres a pretty standard workflow for setting a sysctl value which will
be applied on image boot which was written by tripleo. Lets move this in
tree as other folks (like Octavia) would like to depend on it.
Change-Id: I3c266870d417cdba3196f5fa65c4cd634ab13173
cloud-init-local needs to be run in the boot runlevel because it
modifies services in the default runlevel. When a runlevel is started
it is cached, so modifications that happen to the current runlevel while
you are in it are not acted upon.
Change-Id: Ifeae0071fc9e738ec223ec0df271559ad6e0196b
