The dnf-plugins-core repo updates its download command to use a
dnf.utils method that is not present in the dnf version installed by
Debian packages. Update the fetch of dnf-plugins-core to use the last
version of the download plugin that is compatible with the dnf package
in Debian.
Note that we don't use the bookworm dnf-plugins-core package to address
this because dnf-plugins-core specifies that it breaks and replaces
zypper. There doesn't seem to be a good reason for this as there is no
file overlap between the packages according to `apt-file list`.
Change-Id: I6fbf7db87a8272dae2552f9075addec2d5c82e56
This upgrades our base container image from bullseye to bookworm.
It also removes some backported packages that were only needed on
bullseye.
Change-Id: I4a009f9f0aaf096f172e3daef7419e6d0c691466
OpenDev is moving images to quay.io. This change updates nodepools's use
of those images to match. The depends on will ensure we don't merge this
before the move has occurred.
Depends-On: https://review.opendev.org/c/opendev/system-config/+/881932
Change-Id: Ia879bf22f68a26358a4e28aec6ee4f1c82dbc586
This reverts commit 938d28abe8.
The upstream version is released, so this now causes build failures
due to trying to downgrade the package.
Change-Id: Ibdba6c3332a08691a9a412e5849cb7377c0ec27f
This updates git to address CVE-2022-23521.
Change-Id: Ib08ff1fc7b3c8623fa6b927f3010af72e1b946cf
Co-Authored-By: Jeremy Stanley <fungi@yuggoth.org>
Co-Authored-By: Clark Boylan <clark.boylan@gmail.com>
We are having problems with the ARM64 nodepool-builder container that
appears to be because unstable now has a Python 3.11 package, and
pulling it in conflicts with the container-built version in
/usr/local. It appears the /usr/local install isn't fully isolated
from the system install <insert reason here, it's not clear>.
We can hopefully avoid this by dropping the unstable dependency, which
is not great to have anyway.
stable-bpo has debootstrap 1.0.128 which is the same as unstable. So
we can switch that to install from backports.
The issues with the clone3() system call are included in podman 3.0.1
which is in the stable repos now [1]. So we drop all the unstable
pulling of podman related packages.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995777
Change-Id: Ib3dfda3df69e7ab359b96cd1865e47c7e1e8047b
It seems the containerfile elements are currently failing to have any
networking, meaning they can't update packages, etc.
There's some podman warnings along the lines of
Error validating CNI config file
/etc/cni/net.d/87-podman-bridge.conflist: [failed to find plugin
\"bridge\" ...
which suggests to me containernetworking-plugins isn't installed.
Honestly I'm not sure why we aren't installing it ... it has iptables
as a dependency so we don't need to explicilty install that.
Add it to the install here
Change-Id: Ie1fe48691f44aa847859cf294404dd9e8b03cce8
This adds python 3.11 testing and drops python3.10 in order to keep
testing only the bounds of what Nodepool supports. Note that currently the
python 3.11 available for jammy is based on an RC release. This should
be fine as we do functional testing with a released python 3.11 and that
is what people will consume via the docker images.
Change-Id: Ia3e1c4976e35b254497e60d811f61a5531c69f1a
Per the comments in
https://github.com/containers/podman/issues/14884
there is basically no way to run podman nested in the container in a
cgroups v2 environment (e.g. Ubuntu Jammy) with the processes in the
same context the container starts in.
One option is to run systemd in the container, which puts things in
separate slices, etc. This is unappealing.
This takes what I think is the simplest approach which is to check if
we're under cgroups v2 and move everything into a new group before
nodepool-builder starts.
The referenced change tests this by running the containerfile elements
on Jammy.
Neded-By: https://review.opendev.org/c/openstack/diskimage-builder/+/849274
Change-Id: Ie663d01d77e17f560a92887cba1e2c86b421b24d
This adds python 3.10 testing and updates our docker images to
python3.10.
On the docker image side of things we use opendev's python images which
are based on Debian then have python compiled on top of that external to
Debian python packaging. Debian bullseye ships with python3.9 but our
images come with python3.10. What this means is that we cannot rely on
external wheel caches for Debian bullseye + python3.9 here as we've got
the wrong version of python3.10. The good news is that all of the
dependencies that have historically given us trouble on arm64 in
particular already ship python3.10 aarch64/arm64 wheels. This means we
can rely on pypi as is. This is probably better for us anyway as it
decouples us from relying on additional external resources.
We also update a number of jobs to use nodeset: ubuntu-jammy as this
ubuntu version defaults to python 3.10.
Change-Id: I7fb585bc5ccc52803eea107e76dddf5e9fde8646
When building Ubuntu 22.04 (Jammy), we need ``ar`` as extractor because
dpkg-deb on bullseye doesn't support the required compression algorithm.
Make sure that it is installed in the docker image.
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Icb0e40827c9f8ac583fa143545e6bed9641bf613
As noted inline, use the unstable version of debootstrap to support
later distros.
In an effort to reduce the layers, refactor setting up the unstable
repo earlier where we install debootstrap.
Change-Id: I596d4e129b1617b9d4e52c0d9bc969db906ea4ff
As noted inline, we are having problems running podman on the
production hosts (why this doesn't happen in the gate is still a
mystery...). Explicitly install uidmap package alongside podman.
Change-Id: Ic7817cf1b1279dfde5b4cf9538f5067176024b73
Due to the issues in the bug outlined inline, we need a more recent
podman for the DIB containerfile element with recent distros like
Fedora 35. Install from unstable until these fixes make it into the
stable package.
Change-Id: I6ce1e9c61c0a38dde667efd1fc1f6ba86dfee6e2
After updating images to bullseye
(I21cfbd3935e48be4b92591ea36c7eed301230753) we can use the native
podman packages. These are slightly older, but should be fine for the
intended usages.
Change-Id: Ica62392ebf4a665a04cd65458dda9e0a7545ccc8
Similar to Zuul (I71182e9d3e6e930977a9f983b37743ee3300ec91), the base
images have updated to Bullseye.
This updates various things to get a building Bullseye image.
We have upgrade to 3.9-based images here because OpenDev builds ARM64
wheels for a bullseye+arm64 combo, which we use to speed up the ARM64
cross-build (we do not have any repository of <3.7|3.8>+bullseye ARM64
wheels, so it makes it difficult to use these combos as the
cross-build can take a very long time)
Depends-On: https://review.opendev.org/c/openstack/diskimage-builder/+/806318
Change-Id: I21cfbd3935e48be4b92591ea36c7eed301230753
Configuration has all moved to containers.conf; write the cgroup
option into that. Also disable log messages trying to go to systemd,
which puts out warnings about the journal socket not existing.
Change-Id: Ia4d31d826daf6f9b43757b8b4ae446092afd42c8
It seems some packages that are really quite important are only
recommends depdencies and cause failures when dib containerfile
element tries start podman for extracting base images. Add
--install-recommends.
Since the podman things are getting a little complex now, consolidate
them into one section for clarity.
Change-Id: Ie77ee0a0c5318d8c12eb1b0e68b3b6fa8358ece0
If the kernel in the container doesn't support this option it causes
podman to fail to start when using the containerfile dib element.
Disable metacopy option for compatability.
Change-Id: I168bd1a50b6b20da051b00c3e88daedb5ed6e5e9
This installs podman inside the nodepool container, which is used by
the dependent change in DIB to extract initial chroot environments
from upstream containers. This eliminates the need to run non-native
tools on build hosts (rpm/zypper on Ubuntu, etc.).
As noted in the config, podman defaults to assuming systemd is
installed and using various systemd interfaces.
Additionally, we map the a volume into the container which allows
nested podman to do what it needs to do.
Needed-By: https://review.opendev.org/700083
Change-Id: I6722aa2b32db57e099dae4417955a8a2cd28847e
gdisk includes sgdisk which is used to create GPT partitions on disks.
EFI partitions are vfat so need dosfstools. This is used by DIB when
creating images with a EFI setup as with arm64 image builds.
Change-Id: I57891d6890a3db6acb42c149c3a05ab25f423385
We updated python-base and python-builder to include arm64 images in
support of nodepool's arm64 python-builder image. In doing so we have
discovered a number of issues, but the biggest is slowness of building
python packages in an emulated environment.
In order to speed up package builds we consume the OpenDev linaro
cloud arm64 wheel cache. This doesn't have wheels for every package we
need, but for the things that it does have it will speed up our builds.
One of the risks with this setup is that we're relying on wheels built
for openstack on arm64 and those follow openstack's contraints. In order
to mitigate this risk we set pip install's --prefer-binary flag in the
pip.conf. This means that if openstack's constraints lag what is
availale on pypi we should use the existing wheels as long as they are
valid version according to requirements rather than trying to build from
sdist.
Co-Authored-By: James E. Blair <corvus@inaugust.com>
Co-Authored-By: Ian Wienand <iwienand@redhat.com>
Change-Id: I3b358721eebbceafc12daf9d706306634048b196
These two change are required for arm64 but are also fine for x86
builds. Lets get these in before adding arm64 image jobs as it
simplifies the juggling we have to do with the various fixes.
Change-Id: I051bd0d80fa556111cb36d52391dca264f17015c
We see timeouts trying to get this key fairly frequently in the gate.
Store it locally and use that in the container build.
Change-Id: Ifd706849f1fad88c8ec4afc79090df4afb88abb4
We added two packages to extras so that they'd end up in the
container images, but we never told anything to install them.
It became clear that that's confusing, so we added an api
to python-builder to allow specifying a list of extras to
install.
Depends-On: https://review.opendev.org/722125
Change-Id: I27e10822744863560febcdad8bab9a4f3cf8fc8e
As described in the updated comment section, this debootstrap from the
openstack-ci PPA works around some issues building inside a container.
Change-Id: I0887a801bb6dd4ce992c39d9e332a18f8194a7b9
We have versioned base images now. Pin to 3.7 (the current default)
so that we're explicit. We can update to 3.8 in a followup if we
want to.
Depends-On: https://review.opendev.org/714532
Change-Id: I6f92682b2d7c402af0a77183a71a6fdb2a1fac7d
This code was already reverted in the zuul images, it doesn't
actually provide the value is claims to add and it breaks the
running under podman.
Revert "Dockerfile: add support for arbritary uid"
This reverts commit da2701e0b1.
Revert "Dockerfile: add user to shadow file too"
This reverts commit 747e957263.
Change-Id: Iff606c65c6a3223f13d963d90455fa895193cce8
Our dockerfiles describe the building of many images. Some are temporary
and others persist to publishing, but they all have specific roles and
knowing where to apply changes is important. Unfortanately, it is hard
to see that by default. Experiment with the addition of ==== barrier
lines to give people a visual cue for the divisions.
Change-Id: If28e0bd94a4d65f0623c56e9a589615dd04d2e75
There are some DIB methods which need to use it which means
that DIB image builds will fail without it (and procps is
not included in the base Docker image)
Change-Id: I3cf3ce765a91a93e72465739ce68bc1238955126
vhd-util is needed for targetting Rackspace. debian-keyring is
needed for debian images, ubuntu-keyring for ubuntu images and
yum for red hat images.
Note the sibling build will have installed many of these from the
bindep.txt file from diskimage-builder itself. However, when using
releases this is not done. These installs should be a no-op for the
sibling containers.
Change-Id: I35bc6a2a07fda229acfd53a2a34227d6475495a8
These are tagged as sibling images, and use openstacksdk/dib from Zuul
checkouts. Since we don't want them released to dockerhub, keep the
job separate.
Change-Id: Ifa151e3fb91a8705872989f7d70755e21bb5bf0b
This checks environment variable DEBUG,, and if set will start the
daemons with "-d" instead of "-f". We need the unquoted version of
CMD so that arguments are expanded.
Change-Id: I12685e2b147fc77270678f72bcc18eb429edcb2d
DIB needs sudo to build.
To make it so we only add the sudoers file for nodepool to the builder
image make it so we have a "-base" image, then hang the nodepool,
nodepool-launcher and nodepool-builder images off that.
Change-Id: Ia56aa2f549b8699c382a905708abd55ca2f100af
The APP_DIR directory isn't created, so the container can't start.
Create it and make sure it's owned by the nodepool (10001) user.
Change-Id: Ic119c48482d7bd8f35b6dbb7bf7f350059ec94fc
Without an entry in the shadow file, this user can't use sudo with the
following error:
account validation failure, is your account locked
(which I include here for future googling because it's pretty obscure,
you have to have this odd situation, or a pretty broken PAM to see it).
The "nodepool" user (10001) is in the root group, which is why the
uid_entrypoint script can update the /etc/passwd file. We need to
change the ownership of the /etc/shadow file for this to work. It
feels a bit weird, but there's no password to actually guess anyway.
Change-Id: I8846757edffe31f96df58999d05727910c9fca43
This patch makes the nodepool process avoid starting up as a daemon in
the Docker images, as it's not meant to become a background process
within a container. In order to have consistent logging like in the
daemonized mode we need to add a new foreground option that runs in
foreground but without debug logging.
Change-Id: I77e9e6e4f94cf726336419a2b22916cc1e974e62
Co-Authored-By: Tobias Henkel <tobias.henkel@bmw.de>
We have a utility image that we use for running the nodepool command
that doens't have any additional software installed. Although it does
set a COMMAND of /usr/local/bin/nodepool, it could still be useful as
a general base image for other people if they wanted such a thing.
Change-Id: I894e3d2dbe3cd2017f27ccc5e6fe298e9c9abd03
Use the opendevorg/python-builder image to build nodepool images
with a Dockerfile and multi-stage builds.
bindep wasn't installing gcc for dpkg. Remove the platform restrictions
for it.
Change-Id: I0282b75ffad3d0ae1b589381010a3d4273fceb07
Clark Boylan