NetworkManager takes a distinctly differnet network management
approach and the bulk of the dhcp-all-interfaces code is largely
targetted at distribution specific configuration. Some which may
or may not override settings, or only partially assert desirable
settings.
As such, we need to set appropriate configuration, such as the
correct client to be used, and timeouts based upon user supplied
settings.
By default this change sets the client to be dhclient on redhat
styled machines, as the packaging default, while it works for
ramdisk usage, it does not reset the interface between retries,
which can be critical if the infrastucture operator is attempting
to configure LACP trunks to the end node.
Change-Id: I0e0cfbdbf7ef2b2861b934ccd7dab9d83a35c8f0
Story: 2008001
Task: 40648
Git is a build-time dependency that should not end up in the final
image should source-repositories be the only element requiring it at
image build time.
Change-Id: Id0798c0a753f893d02c2d13fddea0c04b28cb7ca
We are at the point that all distributions we are building have Python
3, so any tools running in the chroot can assume Python 3 exists.
This makes dib-python redundant; mark it as deprecated and start to
remove it from elements where it is no longer required.
Change-Id: I5d852843ec65d3b04444b77c54c5b82424455cd8
CentOS 7 is the only distro we support currently that doesn't have
Python 3 installed in some form in the base images. For centos 7 add
an early install of it in the yum element so we can have all the
in-chroot scripts assume Python 3. There is only one package that
causes issues; yaml which comes from EPEL. Everywhere else it is a
base package, but we don't have a way to say "enable epel to install
this". Just hack it in, we don't want to go reworking the world for
CentOS 7 at this point.
Also add python3 and it's yaml library to the centos 8 path. This
brings in the "user" python3 in /urs/bin/python3 (the "system" python3
is already installed). Again, this just lets us assume
/usr/bin/python3 in scripts for all platforms.
package-installs is one of these things running python in the chroot,
and unfortunately we have elements that use it at 01- level in
pre-installd. Thus to make sure python3 is there nice and early, run
it at 0 level, but make sure it comes after yum/dnf update.
Change-Id: I088fc4284e889147ca9a375d4a159264cff53484
Other architectures are stored under "altarch" for CentOS 7, update
the match.
Convert the delimiters to "," to avoid a subtle problem with "|" --
POSIX states
Within the BRE and the replacement, the BRE delimiter itself can be
used as a literal character if it is preceded by a backslash.
So "s|\(foo\|bar\)|moo|" doesn't do what you might think; the inner
pipe becomes a literal | and this will *not* match "foo" or "bar".
Change-Id: Ic1642325e3a59a10453c356d8d839ce649812af8
Simplify gpg checking by caching a keyring instead of keys to import.
Change-Id: I5ed74ec0e12732aec40ef31377e72d7ddc347f95
Signed-off-by: Matthew Thode <mthode@mthode.org>
Now that DIB is python3 only we can remove a hack that made sure
scripts outside the chroot ran with the correct version of python.
This is necessary as python3 does not resolve symbolic links to the
binary like python2.x did, which causes element scripts to fail finding
modules when DIB was run from inside a venv.
This patch does the following:
1. Reverts 9c7b8d1714 which was the
workaround for mixed python2/3 environments.
2. Updates the scripts to use "python3" instead of "python".
Change-Id: If2402bb02fc8a4778fa9434fa167ea1fafd87c28
With the removal of Python 2.x we can remove the unittest2 compat
wrappers and switch to assertCountEqual instead of assertItemsEqual
We have been able to use them since then, because
testtools required unittest2, which still included it. With testtools
removing Python 2.7 support [3][4], we will lose support for
assertItemsEqual, so we should switch to use assertCountEqual.
[1] - https://bugs.python.org/issue17866
[2] - https://hg.python.org/cpython/rev/d9921cb6e3cd
[3] - testing-cabal/testtools#286
[4] - testing-cabal/testtools#277
Change-Id: I870286a2557e41099597c22dc9747743e1077615
EPEL centos8 have different epel repos like
epel, epel-modular, epel-playground etc, so
we need to disable all not just epel.
Also ensure other epel repositories in CentOS7
like epel-testing are also disabled.
Related-Bug: #1885315
Change-Id: I02b3b83fa2047702d5f069d3ca1c9c0bcc1dab52
DIB was retrieving the oldest cloud image file which, presently, means
retrieving CentOS 8.1 instead of CentOS 8.2. Even though DIB runs a
system update and so catches up to latest, this takes bandwidth, time
and final image space (8.1 + system update = 765M qcow2, vs 8.2 + system
update = 518M qcow2).
This patch fixes that by taking the first image name in a descending
order list.
Change-Id: I648fe19f1f76c03c97492b6ac7be6381f6f9261b
This patch adds support for CentOS 8 Stream [1] to the centos-minimal
element. Users should set DIB_RELEASE=8-stream.
[1] https://www.centos.org/stream/
Change-Id: Id0825de735ab957c10daf35fb3c641f850cc6847
Since the original merge of this code
(04208e7c79) several things have
changed; particularly now we ship dib-run-parts as part of dib, not as
a separate package.
We setup $_LIB to point to the shipped library diretory via
pkg_resources lookups. We now call dib-run-parts (as mentioned,
shipped as a dib library now), source scripts, etc. via $_LIB and thus
do not rely on $PATH. Consequently we don't need this activation
part.
Which is helpful, because "venv" (as opposed to virtualenv) doesn't
have activate_this.py. So this fixes installation under that for
Python 3.
We update the functional tests to use the virtualenv_command exported
by the ensure-pip role, which will test the venv path. There is no
need for dib_python as we are Python 3 only now.
Change-Id: Iede929ea2d278008220aac8b1d678ba41eba0d8a
The standard Python venv module does not have this script, so currently
DIB unconditionally fails. While a real fix will be provided in
https://review.opendev.org/#/c/704478/ this change at least allows
users to try work around the problem.
Change-Id: I45b79d4d283f2b3ea909612e652672dcb6092488
This reverts commit 6ee2995214 and
e85c2a6f03.
I missed that if you pip install and then run dib-lint, it's not going
to pick up the .yamllint file shipped here. Thus it gives spurious
errors.
The reason for this was simply better duplicate key detection in yaml
files, which caused us problems with the kernel installs. However, at
this point it seems just the old "does it load" test from pyyaml will
be enough.
Change-Id: I87a9fc9bb119cfeffad48fc0fa0df31f0181825d
The main reason for using the stage4 is now gone (kernel compile).
Install and use the distro provided binary kernel package.
In addition to this, set the locale and timezone, beyond that very
little was done in the gentoo stage4.
Change-Id: I541b7d9b807e2357398ae1c249b1978958dd1137
Signed-off-by: Matthew Thode <mthode@mthode.org>
As of recently, opensuse-minimal images fail to build because of an
error installing the kernel-default package:
> Problem: kernel-default-5.6.12-1.3.x86_64 requires mkinitrd >= 2.7.1, but this requirement cannot be provided
> not installable providers: dracut-050+suse.61.g0fe0e854-1.1.i586[repo-oss]
> dracut-050+suse.61.g0fe0e854-1.1.x86_64[repo-oss]
The problem is there is a recently added package `busybox-links` which
provides a subpackage `busybox-xz` which provides the /usr/bin/xz
utility. Since this is available, the `aaa_base` package installs it
during the root.d base installation phase to fulfill it's dependency on
/usr/bin/xz. On the other hand, the dracut package explicitly requires
the `xz` package, and this is not co-installable with the `busybox-xz`
package, so the dracut package is not installable during the install.d
phase. This change explicitly adds the `xz` package to the initial
chroot provisioning phase so that the /usr/bin/xz requirement is already
fulfilled and `busybox-xz` does not get installed.
Change-Id: Iba8c301eb496657873963e1aa99736aacf87cb00
This reverts commit 6e549c33ac.
It uses the new multiple-parameter matching format from
Idff7b067ad4255e6fc4138f7eff313a81b75c8ba to actually do what it says.
Change-Id: I4656ff1a5c46bcfbd8587f2f541825f4ad08820f
The change Ia6f10741fa6be24b11d6991c8a6b6e07951ff68d introduced having
"when:" as a list of values. However, this was actually not
sufficient to express the logic required for arm64/x86_64/xenial
kernel matching we wanted.
Because the package name is a key, we can't have multiple entires in
the package-map YAML files. This means we can't do more advanced
matching and thus we need to be able to match through multiple
parameters. Similar to Ia6f10741fa6be24b11d6991c8a6b6e07951ff68d we
modify the matching rules to allow a list.
A an example of using this is provided in the README.rst, and this
same example worked through by the unit tests.
This also slightly updates the matching logic to be more sequential.
After each check we either continue on or log the failure and continue
to the next check (rather than set a list of flags then check that at
the end). This makes it much easier to understand what is being
matched in the logging output from the tool.
Change-Id: Idff7b067ad4255e6fc4138f7eff313a81b75c8ba
This gives us better linting of YAML files that just opening them.
This would have detected the duplicate keys in
I34e27d821fbefe274e7b007f37b0bd34db2e1d26.
The .yamllint is taken from zuul-jobs where it is also used as a
fairly sane set of default rules.
A few minor newline fixes are added.
Change-Id: I96d6644ae24f7deb84fa50fefbda0f0d33e0e009
This reverts commit 14ff8f942c.
This seems to not be installing the kernel at all, and needs further
investigation.
Change-Id: Ifd809d4b67aff5d80f979235db246a16af0375b3
Only install the HWE kernel by default for Xenial. This was actually
installing the 16.04 HWE kernel on Bionic by accident, since it seems
to have that package; however it was breaking Focal.
On the other distros, just install the default generic kernel. Let's
KISS for now if we can ...
Change-Id: I34e27d821fbefe274e7b007f37b0bd34db2e1d26
