This commit fixes wrong name of yum.conf files
on CentOS 9 Stream in centos element to correct ones.
Change-Id: I25f0661fa79b7bc8ac1b8e3b2831a413c4161d1d
The opensuse qcow2 image seems to regularly have a mismatch with its
sha256sum file. Possibly because these are being served by different
mirrors and are out of sync with each other? I have been able to
reproduce this locally downloading each file and comparing the resutling
hash.
Change-Id: Ic849f5b2afa488d9518065084112f8fc6e3083b2
openEuler 20.03-LTS-SP2 was out of date in May 2022. 22.03 LTS
is the newest LTS version. It was release in March 2022 and
will be maintained for 2 years. This patch upgrades the LTS
version. It'll be used in Devstack, Kolla-ansible and so on
in CI jobs.
This patch also enables the YUM mirror to speed up the package
download.
Change-Id: Iba38570d96374226b924db3aca305f7571643823
Somewhere between the upstream container
rockylinux/rockylinux:8.6.20220515 and the latest release, systemd
started to be pre-installed in the container.
With <= 20220515 installing the kernel-core package would end up
pulling in systemd. As part of the systemd package installation, the
/etc/machine-id file is created and populated.
The kernel package post-install steps install the kernel with
/bin/kernel-install; this is responsible for copying the kernel
binaries into /boot. It does this based on the machine-id, and it
seems its failure case with a blank machine-id is to simply skip
copying the kernels into /boot. To compound this problem, it seems
our bootloader installation doesn't notice that we don't have a kernel
installed, so we end up building an unbootable image.
Testing is/was showing us this; but as rocky is non-voting and this
occured at a random time (rather than in response to a dib change) I
think it slipped by us.
To work around this, create the machine-id early in the container. We
already have paths that remove the machine-id from final images.
Change-Id: I07e8262102d4e76c861667a98ded9fc3f4f4b82d
I think that generally this is a lot of noise in the logs, as the
internals of cache-url is well tested, so we don't need to trace log
by default.
Change-Id: I25b5a1ec0d8f99691b2b4b62b9fdd537e5a773e4
This is a squash of two changes that have unfortunately simultaneously
broken the gate.
The functests are failing with
sha256sum: bionic-server-cloudimg-amd64.squashfs.manifest: No such file or directory
I think what has happened here is that the SHA256 sums file being used
has got a new entry "bionic-server-cloudimg-amd64.squashfs.manifest"
which is showing up in a grep for
"bionic-server-cloudimg-amd64.squashfs". sha256 then tries to also
check this hash, and has started failing.
To avoid this, add an EOL marker to the grep so it only matches the
exact filename.
Change I7fb585bc5ccc52803eea107e76dddf5e9fde8646 updated the
containerfile tests to Jammy and it seems that cgroups v2 prevents
podman running inside docker [1]. While we investigate, move this
testing back to focal.
[1] https://github.com/containers/podman/issues/14884
Change-Id: I1af9f5599168aadc1e7fcdfae281935e6211a597
Gentoo can manage python versions itself. Before this commit users were
forced to set python versions themselves. Now they have the option to
set it if they wish.
The workaround needed for git is also no longer needed, so it's been
removed.
Change-Id: I06b259ef73a40df6b8ab92a5b424bffcf4ef764d
Signed-off-by: Matthew Thode <mthode@mthode.org>
The block device lvm lvs `size` attribute was passed directly to
lvcreate, so using units M, G means base 2. All other block device
size values are parsed with accepted conventions of M, B being base 10
and MiB, GiB being base 2.
lvm lvs `size` attributes are now parsed the same as other size
attributes. This improves consistency and makes it practical to
calculate volume sizes to fill the partition size. This means existing
size values will now create slightly smaller volumes. Previous sizes
can be restored by changing the unit to MiB, GiB, or increasing the
value for a base 10 unit.
The impact on this change should be minimal, the only known uses of lvm
volumes (TripleO, and element block-device-efi-lvm) uses extents
percentage instead of size. The smaller sizes can always be increased
after deployment.
Requested sizes will also be rounded down to align with physical
extents (4MiB). Previously specifying a value which did not align on
4MiB would consume an extra extent which could unexpectedly consume
more than the partition size.
Change-Id: Ia109cc5105071d82cc895d8d9cb85bc47da20a7a
All indication in CI is that Centos Stream9's use of dhclient
appears to point to compatability issues when interacting with
dnsmasq. However, this doesn't appear to be the issue with the
internal dhcp client. As such, lets constraint the RH default
so that it no longer applies to Centos 9-stream.
I've also added a documentation entry for DIB_DHCP_CLIENT which
was previously undocumented.
As an aside, I've already reached out to RH's NetworkManager team
regarding this, but root cause is not entirely understood at this
point.
Change-Id: I235f75b385a8b0348c8fe064038c51409f8722c4
Story: 2010109
Task: 45677
Creating a separate /boot partition is desirable in some cases[1].
This change detects if /boot is a partition, and ensures that the
kernel/ramdisk paths are correct in either case. This is applied to
all BLS entries files, whether they were generated by the previous
grub2-mkconfig call or in the source image.
This means the rhel9 specific workaround can be removed since all
paths are now normalised at this stage.
[1] https://review.opendev.org/c/openstack/tripleo-image-elements/+/846807
Change-Id: I62120ec8c65876e451532d2654d37435eb3606a6
Resolves: rhbz#2101514
Currently if no Dockerfile is specified or found, we exit later with
an obscure error. Check this after the element search; if we still
don't have something to build then we can't continue.
Change-Id: Ifb17a0995fab0ccfe7ee08363676c1fa57e37592
Unit tests are currently passing on python 3.10, and distributions
shipping python 3.10. Mark dib as supporting this in setup.cfg
Change-Id: I32dfefbe4bf5285d94b92822fd64141b748ae9ef
'9-stream' was being matched against the regex '9',
causing builds on RHEL9 to try to install C9S RPMs.
We want this the other way so that DIB_RELEASE=9
will not match the regex '9-stream'.
Resolves: rhbz#2097443
Signed-off-by: Lon Hohberger <lhh@redhat.com>
Change-Id: Iefd7c23512c460e33117d12bbc33606134daa9e2
Add a warning in satellite configuration as when no activation_key
is provided and no environment is configured, subscription-manager
might hang as it's prompting the user to provide the missing
parameter.
Change-Id: I9564841ca845eafc2bd39be6b05bef62e8062f28
We want to be more flexible in terms of selecting which python versions
we test against. So replace the use of the openstack template with
explicit job invocations.
Change-Id: I2159e81d4a2fd46a83993b01bbea5fb37546ace5
We want to be able to support older Python versions than those that are
possible with the current OpenStack constraints. Run unit tests without
constraints instead.
Change-Id: I4237a56ff9733b5e3c9521193cc5e9758c28095e
Due to the referenced inline issue, 9-stream currently fails running
setfiles in a chroot without /proc. Since we want to actually label
/proc, we don't want it mounted. This pulls in the fixed packages to
get things going until the fix is rolled out.
Change-Id: Id41c16130e975779cb70e2ab19807a689450d026
This reverts commit fe0e5324d4.
Reason for revert: Python3.6 is still being used on Centos 8 based
platforms.
This is a partial revert, since the py36 job is currently failing, it
will be restored in a follow-up patch.
Change-Id: Idc0373f9a639cd66925543376fb1e2e3398666da
Although we're not on the OpenStack release schedule as such, Zed
cycle is dropping 3.6/3.7 support. This means it seems like as good a
time as any to also update ourselves to this regime. One important
dependency to think about is nodepool, but that is already >3.8 only
so we will be in sync there.
This also changes dib jobs to run using the zed template and adapts
the bindep file to handle Ubuntu Jammy.
[1] https://governance.openstack.org/tc/reference/runtimes/zed.html
Change-Id: Ibdbcf459608711ac64e7fefb1707f6708d68e750
Co-Authored-By: Jay Faulkner <jay@jvf.cc>
Co-Authored-By: Jens Harbott <frickler@offenerstapel.de>
Co-Authored-By: Ian Wienand <iwienand@redhat.com>
When building an image, say RHEL9, on a host installed with that
same image, you will be blocked from mounting the filesystems to
extract contents, as the host OS kernel will identify the duplicate
UUIDs and error accordingly.
This was previously fixed for the root filesystem, but not the boot
filesystem.
Change-Id: I63a34fba033ed1c459aeb9c201c8821fa38a36e9
