Without the dialog package is not possible
to properly use an interactive frontend.
debconf will print the following errors:
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed,
so the dialog based frontend cannot be used. at
/usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76, <> line 1.)
Change-Id: I0c7142f717cacf7437dbac1e1696f39b00cb4c49
We have a pkg-map entry for lsb_release, but in package-installs.yaml
we refer to the actual package name instead. This will happen to
work on Red Hat platforms, but it's actually wrong.
Change-Id: Idb248f96e75fa1090422fa08e5fbb2385cc1f517
yumdownloader has to have all the repo XML files, etc, which adds up
to a not totally insignificant 150MiB or so. Currently we're leaking
this directory for every build, which adds up on regualar builders
like nodepool.
Isolate the call with a separate TMPDIR so we can clean it up after
the initial download.
Change-Id: Ic65e8ca837cc76b7a1bb9f83027b4a5bdd270f75
Remove the x bit from lib/disk-image-create; because it's called
directly by the entry-point, it doesn't need to be exectuable.
This should also be clearer that you're not supposed to run it
by hand.
Remove some boilerplate from old file
Change-Id: Ibb6cdae613e6c9cf21dd6aecc8e1f739bc3a2643
Move dib-run-parts from dib-utils into diskimage-builder directly.
For calling outside the chroot, we provide a standard entry-point
script. However, as noted in the warning comment, the underlying
script is still copied directly into the chroot by the dib-run-parts
element. I believe this to be the KISS approach.
This removes the dependency on dib-utils. We have discussed this
previously and nobody seemed to think retiring dib-utils was going to
be an issue.
This also updates the documentation to not mention dib-utils, or using
disk-image-create via $PATH setup, but rather gives instructions on
installing from pip with a virtualenv.
Change-Id: Ic1e22ba498d2c368da7d72e2e2b70ff34324feb8
while using disk-image-builder for building overcloud images for TripleO
using RDO, this repository is (in my opinion) wrongly disabled because
contains certain dependencies needed by RDO packages.
Example: python-cheetah is required for python-nova, but is not
available through RDO repository but only from
rhel-7-server-rh-common-rpms
Closes-Bug: #1638938
Change-Id: I76824c8ec02590397f1ff1d4f177ad061c7bf441
Signed-off-by: Luca Lorenzetto <lorenzetto.luca@gmail.com>
Mount all the usual /dev /sys /proc pseudo filesystems during the
root.d phase in order to make sure they are available for the rpm
post-installation phases.
Change-Id: I28221debf1036d9eb5137161757eb30811eafab1
On Centos and RHEL 6 the init system is upsart but but networking is using
sysv compatabiliy and a code path the handle this situation.
We can't use DISTRO_NAME because the centos-minimal element sets it to
centos for CentOS 7 but the centos element sets it to centos for CentOS 6.
Change-Id: Ib8e33ed78b3d6a5737eb7449bccef2d33f72b131
Closes-Bug: #1638527
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>
