Luan Nunes Utimura 5fa60a5421 Add sources.list for non-default layers
After reestructuring `deb-local-binary` into multiple binary
repositories, one for each layer, the image build now has access to
three repositories by default:

  * deb-local-binary;
  * deb-local-binary-containers;
  * deb-local-build.

Although these repositories are sufficient for the vast majority of
images, there are some, such as `stx-openstackclients`, that require
dependencies that are found in another repository:
`deb-local-binary-openstack`.

This image, as the name suggests, contains all the OpenStack clients
currently supported by the StarlingX OpenStack application.

As one can see in [1], although most clients are installed in the form
of pip packages, i.e., through wheel files collected from the upstream
indexes, there are two clients that are installed in the form of
distribution packages:

  * python3-cinderclient;
  * python3-openstackclient.

The reason why they are installed as distribution packages is because
they have patches that are specific to StarlingX OpenStack -- [2] and
[3] -- and also because the build procedure can easily identify them in
`deb-local-build` and use the patched versions as expected by us (of
course, it they have been built previously).

The problem, however, is that although this image is currently being
built, there is a detail in it that can cause problems at run time.

Despite the build locating (and using) our patched packages, when it
searches for their dependencies, it always ends up using binaries from
repositories `deb-local-binary`, `deb-local-binary-containers` or
`deb-local-build`.

Which means that, if we have a dependency on
`deb-local-binary-openstack` meant for OpenStack Antelope, and the same
dependency on `deb-local-binary` meant for OpenStack Victoria, the image
build will use the latter, for the simple fact that it do not consider
the `openstack` layer (and, therefore, `deb-local-binary-openstack`).

To get around this problem, this change seeks to add a `sources.list`
for each build layer. By default, they are all disabled. However, if
necessary, they can be enabled and used in image builds based on Docker
or LOCI.

Note: This change is the prerequisite of [4].
      The test plan with the `stx-openstackclients` image will be done
      there.

[1] https://opendev.org/starlingx/openstack-armada-app/src/branch/f/antelope/upstream/openstack/python-openstackclient/debian/stx-openstackclient.stable_docker_image#L26-L27
[2] https://opendev.org/starlingx/openstack-armada-app/src/branch/f/antelope/upstream/openstack/python-cinderclient/debian/patches
[3] https://opendev.org/starlingx/openstack-armada-app/src/branch/f/antelope/upstream/openstack/python-openstackclient/debian/patches
[4] https://review.opendev.org/c/starlingx/openstack-armada-app/+/896462

Test Plan:
PASS - Build `stx-debian` base image
PASS - Build all container images with --clean and confirm that:
       1. All container images were built successfully;
       2. All container images were removed successfully.

Partial-Bug: 2037339

Change-Id: I36d1af990afad9fd69b723bf3a13b88673dd08ad
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
2023-09-26 20:34:21 -03:00

125 lines
4.4 KiB
Docker

# Start with an the old-ish bullseye release (11.2), then upgrade --
# to make sure packages that come pre-installed in the debian:XXX image
# are older than anything in StarlingX.
ARG RELEASE=11.2
FROM debian:${RELEASE}
ENV DEBIAN_FRONTEND=noninteractive
# Install latest ca-certificates
RUN apt-get -y update && \
apt-get -y --no-install-recommends --no-install-suggests install ca-certificates
# Disable upstream debian repos
RUN mv /etc/apt/sources.list /etc/apt/sources.list.disabled
# Install apt repos
COPY apt/debian.sources.list /etc/apt/sources.list.d/debian.list.disabled
COPY apt/stx.sources.list /etc/apt/sources.list.d/stx.list.disabled
COPY apt/stx.preferences /etc/apt/preferences.d/stx
# Install layer-specific binary repositories.
# Note: They are all supposed to be disabled by default, but can be optionally
# enabled if it is necessary to build an image that requires
# dependencies that are in repositories not listed in `stx.sources.list`.
COPY apt/*.layer.sources.list /etc/apt/sources.list.d/
RUN for layer in /etc/apt/sources.list.d/*.layer.sources.list; do \
mv "${layer}" "$(echo "${layer}" | sed s/.layer.sources.list/.list.disabled/)"; \
done
# repo templates:
# /etc/apt/sources.list.d/
# debian.list.disabled - vanilla debian repos
# stx.list.disabled - starlingx binary & build repos
#
# To enable a repo list:
# cp /etc/apt/sources.list.d/$repo_list.disabled \
# /etc/apt/sources.list.d/$repo_list
#
# To disable a repo list:
# rm -f /etc/apt/sources.list.d/$repo_list
#
# By default only stx.list is enabled, which includes only the packages
# built by stx tools, and the binary packages from the curated binary
# download lists (bullseye-base.lst etc).
#
# Enabling the upstream repos ("debian.list") is dangerous because it
# may conflict with packages in stx.list.
#
#
# FIXME: apt evaluates these files in alphabetical order, so stx.list
# comes after debian.list. When the local binary repo contains
# the same package/version as the debian repo, apt will download
# it from debian, regardless of the priority in /etc/apt/preferences.
# We should rename these files to make stx.list sort before
# debian.list. This would affect Loci scripts in
# loci/docker/stx-scripts/
#
#
# Upgrade base packages to versions in managed repos
#
RUN cp -f /etc/apt/sources.list.d/stx.list.disabled /etc/apt/sources.list.d/stx.list && \
apt-get -y update && \
apt-get -y upgrade && \
rm -f /etc/apt/sources.list.d/stx.list && \
apt-get clean && rm -rf /var/lib/apt/lists/*
#
# Install packages provided only by debian.
# FIXME: move these packages + their dependencies to debian download lists in
# starlingx/tools to avoid referencing the debian repo at all.
#
RUN cp -f /etc/apt/sources.list.d/debian.list.disabled /etc/apt/sources.list.d/debian.list && \
cp -f /etc/apt/sources.list.d/stx.list.disabled /etc/apt/sources.list.d/stx.list && \
apt-get update -y && \
apt-get install -y \
libapache2-mod-wsgi-py3 \
python3-setuptools \
build-essential \
&& \
rm -f /etc/apt/sources.list.d/debian.list && \
rm -f /etc/apt/sources.list.d/stx.list && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
#
# Enable stx repo only. Packages installs below this point will use
# only the managed locally-built & 3rd-party repos.
#
RUN cp /etc/apt/sources.list.d/stx.list.disabled /etc/apt/sources.list.d/stx.list
#
# Install required packages
#
RUN apt-get update -y && \
apt-get upgrade -y && \
apt-get install -y \
openssh-client \
python3 \
python3-pip \
python3-wheel \
# FIXME: uncomment once qemu is ported to debian (starlingx/integ)
# qemu-utils \
&& \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
# FIXME: these packages are not required by most docker images inheriting
# from this image. However these Python modules are not buildable from
# source (ie by pip) on Debian and require patches. Install the patched
# versions as DEB packages to make sure pip dependencies in derived images
# are satisfied.
#
# A better solution would be to omit them here, but install them in each
# project that requires them; or add wheel subpackages to these DEBs.
RUN apt-get update -y && \
apt-get upgrade -y && \
apt-get install -y \
python3-thriftpy \
python3-nss \
python-nss \
&& \
apt-get clean && \
rm -rf /var/lib/apt/lists/*