NetworkManager is quite capable to do automatic
interface configuration. NetworkManager will by default
try to auto-configure any interface with no configuration.
It will use DHCP for IPv4 and Router Advertisements to
decide how to initialize IPv6.
It will most likely do it just as good, or better than the
dhcp-all-interfaces.sh script.
Since dhcp-all-interfaces clean out all ifcfg files in
60-remove-cloud-image-interfaces it means NetworkManager will
by default attempt auto configuration for all interfaces.
This change add's and environment variable:
DIB_DHCP_NETWORK_MANAGER_AUTO (default: false)
When DIB_DHCP_NETWORK_MANAGER_AUTO is set to `true` only the
NetworkManager config will be written. The dhcp-all-interfaces
service will not be installed. Hence dhcp-all-interfaces will
not write any config files, allowing NetworkManager to just do
it's thing.
Change-Id: Id6f8d6aaaf52a78175bb6c065ec88274c364834e
In the grub2 element the grub2-efi-x64-modules package
is missing in the centos 9 section, this cause a failure
because grub2 cannot find the neccecary files when
installing the bootloader on EFI systems.
It seems grub2-efi-x64-modules was not included in release
9, this is likely why the block was added initially without
this package. Since it is now there, the Centos 9 specific
block is no longer needed.
Removing the rhel 8 block as well, as it is identical to the
family "redhat" block i.e it is redundant.
Closes-Bug: #1957169
Change-Id: Ia6b0ecf0cd15fb23c6740543940ee513a8602afe
This change removes the uninstall grub2-efi which was required for
prerelease rhel-9 images but now breaks current centos-9-stream
images. A different approach may be required for rhel-9 if the base
image remains different to centos-9-stream (such as populating the
empty /boot/efi partition from the base image)
This change also fixes the detection of whether this is an efi build
to check the block device instead of checking for whether a grub efi
package is installed. This fixes building a centos-9-stream whole-disk
image when package grub2-efi-x64 is installed but a legacy fallback
grub also needs to be installed.
Change-Id: I24baf553e1acd15a66737fc0b2a79d5335e28aa5
Partial-Bug: #1957789
Per the bug mentioned upstream, grub2-mkconfig will currently not set
the kernel options for BLS entries prefixed with a machine-id
different to the running system.
This affects the centos element, as the upstream .qcow2 comes with a
pre-existing BLS entry but a blank machine-id. This only affects
9-stream -- prior releases either don't use BLS or have entries
configured to use a common variable from grubenv which is updated
correctly.
We currently can not end-to-end test this in OpenDev because we run
our functional tests on Ubuntu Focal (they use devstack), whose kernel
can not read the XFS format on the 9-stream .qcow2. This expands the
functional tests (that run on Debian Buster, with a later kernel) to
add the vm element, so the bootloader path is exercised (this requires
a block-device too). This at least runs the bootloader install, we
can confirm the kernel options look right from the dumping provided
the logs.
Change-Id: I327f5e7a95e47905c01138c8c4483f3f03e8efff
The pip_args variable is not initialized when installing pip for
bullseye resulting in an unbound variable error when running
install_python3_pip on that debian version.
This patch fixes the issue moving pip_args inizialization to a common
place.
Change-Id: I1603c97871449b4f73e3062a705d655e9454bf33
A lack of space between package names was causing apt to fail.
[0] I2b75afd310f009ae8614f6ca75bb984b56d25c45
Change-Id: Ia7e005c2f583037ee44a3c364e3b8d79d51e03a2
Debian bullseye has removed python-pip and python-virtualenv
from its repos, let's install only pip and virtualenv python3 modules.
Also split pip installation based on python2 and python3 for
debian-based distributions.
Change-Id: I2b75afd310f009ae8614f6ca75bb984b56d25c45
This reverts I2701260d54cf6bc79f1ac765b512d99d799e8c43,
Idf2a471453c5490d927979fb97aa916418172153 and part of
Iecf7f7e4c992bb23437b6461cdd04cdca96aafa6 which added special flags to
update kernels via grubby.
These changes actually ended up reverting the behaviour on Fedora 35,
which is what led me to investigate what was going on more fully.
All distros still support setting GRUB_DEVICE in /etc/default/grub;
even the BLS based ones (i.e. everything !centos7).
The implementation *is* confusing -- in earlier distros each BLS entry
would refer to the variable $kernelopts; which grub2-mkconfig would
write into /boot/grub2/grubenv. After commit [1] this was reverted,
and the kernel options are directly written into the BLS entry.
But the real problem is this bit from [2]
get_sorted_bls()
{
if ! [ -d "${blsdir}" ] || ! [ -e /etc/machine-id ]; then
return
fi
...
files=($(for bls in ${blsdir}/${machine_id}-*.conf; do
...
}
i.e., to avoid overwriting BLS entries for other OS-boots (?),
grub2-mkconfig will only update those BLS entries that match the
current machine-id.
The problem for DIB is that we are clearing the machine-id early in
finalise.d/01-clear-machine-id, but then running the bootloader update
later in finalise.d/50-bootloader.
The result is that the bootloader entry generated when we installed
the kernel (which guessed at the root= device, etc.) is *not* updated.
Even more annoyingly, the gate doesn't pick this up -- because the
gate tests run on a DIB image that was booted with
"root=LABEL=cloudimg-rootfs" the kernel initially installed with
"install-kernel" (that we never updated) is actually correct. But
this fails when built on a production host.
Thus we don't need any of the explicit grubby updates; these are
reverted here. This moves the machine-id clearing to after the
bootloader setup, which allows grub2-mkconfig to setup the BLS entries
correctly.
[1] 4a742183a3
[2] https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0062-Add-BLS-support-to-grub-mkconfig.patch
Depends-On: https://review.opendev.org/c/zuul/nodepool/+/818705
Change-Id: Ia0e49980eb50eae29a5377d24ef0b31e4d78d346
Patch allow to set path for local image source,
instead download latest or use the cached image.
This permit to build image also in environment without internet access.
re-propose of patch: https://review.opendev.org/c/openstack/diskimage-builder/+/809009
Change-Id: I54395b09af339caee040326b809e8fbf8b0e7d6a
A recent(-ish) change in git [1] has exposed a bug in caching that
appears in one very specific circumstance -- updating the
openstack/openstack super-repo [2].
This repo gets a submodule update every time something is pushed. By
using "--git-dir" while the cwd is one-level above the actual repo we
are confusing [1] which is not finding the submodule directories
correctly and giving us an error:
Could not access submodule 'foo'
for every submodule that has updated between now and the last time we
updated the cache. [3]
The git manual does warn about this
If you just want to run git as if it was started in <path> then use
git -C <path>.
Indeed, that is what we want to do in this path. Modify the calls to
use -C.
[1] 505a276596
[2] https://opendev.org/openstack/openstack/
[3] The result for opendev production is that image builds fail every
time an openstack/* project is checked in; we then race to retry
the build before another commit lands and updates the submodules
again.
Change-Id: Iadb23454e29d8869e11407e1592007b0f0963e17
Refactor things to use explicit names, and put in a trap to cleanup
after any errors.
Currently, if the build/run/export steps fail, it leaves behind images
which eventually clog things to the point podman won't run any more
(see also https://github.com/containers/podman/pull/12233 about errors
seen due to this)
Change-Id: Ib328a07ad67e3f71f379fbf34ae7ef74e212ef1c
Ic68e8c5b839cbc2852326747c68ef89f630f26a3 removed the sudo from the
tar extraction here, meaning that production is failing to create the
chroot. This is hidden in testing because
DIB_CONTAINERFILE_PODMAN_ROOT is set. Make the sudo here
unconditional.
Change-Id: I6e36e3fc65981f85fad12ea2cd10780fde9c37da
CentOS Stream 9 is close to be released, and official mirrors are
already poplated. This patch is adding support to centos-minimal in CS9.
Also enable centos-minimal/[8,9]-stream-build-succeeds tests.
This patch is being tested together with [1] to apply following list of elements:
vm centos-minimal simple-init growroot nodepool-base openstack-repos infra-package-needs
[1] https://review.opendev.org/c/openstack/project-config/+/811442
Change-Id: Iecf7f7e4c992bb23437b6461cdd04cdca96aafa6
The if/elif block added in [0] doesn't work for gentoo, let's hope
that we can get along with an easy fix.
[0] https://review.opendev.org/c/openstack/diskimage-builder/+/804000
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: I543e04d2d7efea3e718bae31aa1cc4767bd359f8
This adds 9-stream support to the centos element.
See https://review.opendev.org/q/topic:cs9 for related patches.
Change-Id: Ib80fbd21edb77c25764eff2c0d66e55bde7a90af
We need to update the base reference platform we perform the
functional tests on. Debian bullseye seems like the best choice -- it
is recent enough to last for a while, and will match the
nodepool-builder container environment.
Depends-On: https://review.opendev.org/c/zuul/zuul-jobs/+/814088
Change-Id: Ic68e8c5b839cbc2852326747c68ef89f630f26a3
I'm not aware this element is used/was ever used. It hasn't ever been
updated to Focal. To reduce our testing footprint remove this test,
and note in the element its probably broken.
Change-Id: I17cd3b13948287fe78990cfbe16a22919a329ba9
This reverts commit 1f4fb1d7a5.
This unfortunately wasn't actually tested. Because the image-based
tests run sequentially, a prior failure in the centos-8 job meant the
ubuntu job never ran.
This is failing with
10-cache-ubuntu-tarball: line 28: DIB_LOCAL_IMAGE: unbound variable
There is also a seemingly unused variable DIB_IMAGE_LOCAL_FILE; I'm
not sure what this is doing.
For now revert, and it can be re-proposed with appropriate testing.
Change-Id: I0f3897c90dc863ee04c3295b9cb094f02d8658e3
It looks like upstream have changed this line to "download.example",
breaking our subsitution. Let's do a generic match.
Change-Id: I8e443022a5f239b98ccefe73a9abf8cf259dc8e9
