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
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
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
Add a new opensuse-minimal element to build small and highly
configurable openSUSE based images using the zypper-minimal element
as the main building mechanism
Change-Id: Iebfc4ad4aff763e511b093f1607b55851ccbddcb
All SUSE-based elements can benefit from the mkinitrd phase to move it
to a more generic location.
Change-Id: Ife171d462a393b6ac0bf2c5eaa48ea25eaf4d1cc
Since http://httpredir.debian.org is unreliable is selecting a mirror
to use, we'll now default to http://ftp.us.debian.org/debian. In
fact, in openstack-infra we have been overriding httpredir.debian.org
for a while, now make this default in diskimage-builder.
Change-Id: I48658bc076e13a0913821197e4120c73618fef8f
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Move the opensuse utilities to the zypper element so they can be used by
SUSE or zypper based elements. This brings the zypper element somewhat
in line with the rest of the package manager elements.
Change-Id: I8aa2849231454216cdd47629a5e2d6e45769dbbe
Depending on the pool id used, so many repos are brought,
including not valid ones that cause image to crash, or repos
that include conflicting packages.
Before enabling repos, disable all previous ones, so we
can be sure that we only bring the repos specified in the
parameters.
Change-Id: Ifd4d8d1d4fa954cd2593669e516e3201f2d6f6c1
Move managing of SSH host keys into a dedicated element.
Because glean doesn't generate SSH host keys anymore, we need to do it
with a systemd script. This is already handled by CentOS / Fedora so
we don't want to add it there.
This was done to address the upstream bug in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500192
Change-Id: I31ad667672e08350872db21a83445fe0aa7a4a39
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Grub is first removed and then installed during RHEL image building. The
grub2 package typically requires the same version of grub2-tools, so if
we just remove and install the grub2 package, the installation can
potentially fail on being out of sync with grub2-tools version. Removing
and reinstalling both packages fixes this issue. Those packages are
already in package map for RHEL as "grub-pc", so we can use this alias.
Change-Id: Iefd9c17fffd43de3fea260510ad218b1322eecb3
Closes-Bug: #1627000
We are currently wasting about 10 minutes per deploy waiting for
DHCP on interfaces that will never get it. By default, the timeout
seems to be 5 minutes (the 10 minutes is because we boot both the
IPA ramdisk and the deployed image, and each waits for 5 minutes),
which is excessively long to get a DHCP response. This change
shortens the time to 30 seconds. If an interface hasn't gotten a
response in 30 seconds, chances are it's not going to. A 30
second wait should reduce our wasted time to 1 minute, which is
more reasonable.
This is being done in the systemd unit file because the -timeout
option to dhclient doesn't seem to override what is configured in
dhclient.conf, and doing it in the systemd file means that this
change will be limited to only the interfaces configured by
dhcp-all-interfaces.
Change-Id: Ia8610e3def39c937eb0c861fdc9bc571ec39f9f4
Closes-Bug: 1626673
Because we are using the building platform's "yum" to do the initial
install into the chroot, it is affected by the base-system's
/etc/yum.conf.
pip-and-virtaulenv in I82acb865378a0fa5903a6267bfcee0e2962eced0 added
"exclude=python-pip..." in /etc/yum.conf to stop the package manager
overwriting the installed pip. Now our CI images have built with
this, we are now picking up this exclude on centos. Since on F24
dnf->python->python-pip we end up failing to build the the chroot
because python-pip can not be satisifed. In a general sense, however,
this could be caused by any configuration put into /etc/yum.conf that
is incompatible with installing into the chroot.
yum has the option to disable all excludes which is used here. This
seems to be the best way to isolate the chroot install from any
excludes that may have been done on the base system for various
reasons. I did consider using a completely separate yum.conf we ship
with dib ... but let's start simple.
This should fix the current gate failures on centos
Change-Id: I4e4cc8ed09a29c4057ade34ea93025139e191bf5
yum-minimal installs selinux but not libselinux-python, which makes
interacting with the node from ansible hard fail. Add it.
Change-Id: I403e7806ae10d5dd96d0727832f4da20e34b94c7
