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
the command had one error in it (missing one backslash)
and was rendered wrong, w/o any backslashes at all.
Change-Id: If187f645b818f47d10b602ccee12c29892a8d88d
After some recent reordering[0], the /boot/grub directory isn't created
early enough on Gentoo any more, let us just ensure ourselves that it is
in place when we create the grub config.
[0] I8cb34914bbbfa05521bbb71cc6637368b980358f
Change-Id: I8a84d08c3090e46b00d1d626fb984f66ea33f256
Previously a module version was splitted from the module name:
nvidia, 510.47.03, 5.4.0-109-generic, x86_64: installed
In Jammy it is now a part of the name:
nvidia/510.47.03, 5.15.0-27-generic, x86_64: installed
Assuming the fact that it would be threatted as a path this change
doesn't brake anything which was working before. But at the same
time it allows to pass last step where dkms is requested to build all
modules.
Change-Id: Ic1bb2b45f9db906b64ca03ae5c4e05b2114f2a74
It may happen a base image has an edited version of cloud-init
"cloud.cfg" that prevents the host keys to be generated.
While it didn't represent an issue with older releases of cloud-init,
starting cloud-init-22 this isn't true anymore.
Before that release, an sshd-keygen@.service was present and called by
sshd-keygen.target (which was called by sshd.service), and we ended up
with ssh host keys in any cases - either generated from cloud-init, or
generated by sshd-keygen.service.
But cloud-init-22 introduced an edition to the sshd-keygen.service,
making it check for the presence of cloud-init service, and preventing
this sshd-keygen to kick in this case.
So we'd better ensure cloud-init is able to generate the keys, else
we'll be in a bad state, since it's instructed to remove the ones
present.
Closes-Bug: #1971751
Change-Id: I37b2f3e9d57a86544ef14e74a4a927309c18bbf0
This adds arm64 ubuntu-minimal Jammy functests and x86 ubuntu image
based Jammy functests. To make this happen we have to install
debootstrap from debian unstable on the functest nodes in order to get
access to a debootstrap that knows what jammy is.
As we ramp up Jammy support in our tools having good testing will be
helpful.
Change-Id: I1d1dc752ce176457d0656cbd50e27a2721ca9856
In the last few hours, OpenSUSE has published an updated cloud image
with a mismatched SHA2-256 checksum file, so the functest jobs has
started failing. We'll revert this as soon as it's working again.
Change-Id: Id4cb15456db779a22ffc9b6fd6916bcb9e5d8270
This makes 03-reset-bls-entries consistent with rhel so that the glob
match is *.conf, and a check is added to ensure that a rename is
actually required.
Change-Id: I4adff43cf7d4f31d939e6ddf37ac8d162ccd0db7
The release-notes-jobs project-template ceased publishing release
notes in the tag pipeline in 2018 when
https://review.opendev.org/622430 merged. Projects were expected to
switch their master branches to release-notes-jobs-python3 instead
around that time, but DIB seems to have missed the boat. Update to
the modern one so that we'll go back to updating our published
release notes every time a new release is tagged.
Change-Id: I9268811438d690d3f945b5d651b8b2ff6220bb96
