This change bumps up the maximum supported version of Ansible to 8.x
(ansible-core 2.15.x) and minimum to 7.x (ansible-core 2.14.x).

Depends on:
https://github.com/stackhpc/ansible-role-systemd-networkd/pull/10

https://github.com/stackhpc/ansible-role-dell-powerconnect-switch/pull/13

https://github.com/stackhpc/ansible-role-mellanox-switch/pull/8

gateway_ip was being set to empty string. This was triggering neutron
""Invalid input for gateway_ip. Reason: '' is not a valid IP address."
Omitting by default.

Installing openstack.cloud collection.
Upgrade failed as Ansible in kayobe-venv was not upgraded.

Change-Id: Ia3550644e5fc3e83f792e46d42b4c35d5eec4705

Setting network mode to host.
Enables testing without additional configuration of the host.

Change-Id: I46406d414290ed785a4644c88cbc76ff074e96a2

Change-Id: I12ad980ef6d30ea98966c0f4eaf047e8d57a40e7
Closes-Bug: #2039558

Stop using openstack-python3-jobs template, because Ansible 8 does not
support Python 3.8.

Change-Id: I8f5338b7eee31f1b8bc3e783d10666e3092a6540

This variable is not supported since
I61a61ca59652b13687c2247d5881012b51f666a7, but was not removed from
etc/kayobe/kolla.yml in that change.

This change also adds the replacement variable docker_registry_insecure
to etc/kayobe/docker.yml.

TrivialFix
Change-Id: I3fa96f0276e08a6678e5d743399d01bc19a8dd1b

Change-Id: I42c4a44afe8b0b19a2d7d14d9b748bf1e2ca5c10

We are seeing an issue on Rocky Linux 9 where VLAN interfaces on bridges
have their MTU set to MTU-1 after rebooting. This is likely related to
how MTU is set by NetworkManager for bridges: it first sets the MTU to
MTU-1 before setting it to the correct value [1].

We can work around this issue by not explicitly setting the MTU
configuration on the VLAN interface if it is the same as the parent
bridge. It will be automatically inherited from the parent.

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/864872e9a8c694ee7472154bf45f869040310b71

Closes-Bug: #2039947
Change-Id: I23366f4de7842e7c2fe40e431fac76f26e9892de

Change-Id: I5151e7be611b95f52c05422c03dafe666dba144e

This release includes the following fixes:

* Remove nmconnection files generated by cloud-init
* Remove ens3 also from NetworkManager config

Closes-Bug: #2039975
Change-Id: Id3e7913f4ba9d05cec332dab560fc42d44dd4130

Follow on to Ie17ef9ce1147cbaec2e42db932c7d59293b49b1b

Adds seed_deploy_containers_registry_attempt_login variable to seed.yml,
which acts as a redirection of deploy_containers_registry_attempt_login
so that the variable is more descriptive, declared in a better location,
and extensible to other groups

Change-Id: I86d8f13062ff8e664919cd5d63bc17bdafb32e0c

Closes-Bug: #2038889
Change-Id: I4609494d009c6e1f97d833a9a11529d107b3216f

Stop configuring the seed host as gateway when seed SNAT is disabled
(which is the default since Xena), otherwise overcloud hosts may take a
long time to gather facts until their network configuration is applied
(probably because DNS servers are thought to be reachable until the
gateway is changed or removed).

Closes-Bug: #2039461
Change-Id: Ib847d3420dee374cec067cd8af519b510be04120

Change-Id: Ie443038dfd9ac63a5945d6b4e9e0eb724f11df44

Change-Id: I7ef0c5240585bfdc27fbdf6b32edd5b51ce2d147

Back in the Ussuri release, we changed the Bifrost kernel location to
use ipa.kernel instead of ipa.vmlinuz. While this works fine for newly
discovered nodes, any node added to Bifrost in Train or earlier will
have kept ipa.vmlinuz as its deploy kernel.

This can cause issues since upgrading Bifrost or building new deployment
images will update ipa.kernel, but not ipa.vmlinuz, resulting in nodes
booting with an old kernel and a new ramdisk.

Fix by adding a new rule updating the legacy kernel location and
documenting how to update node information.

Change-Id: I6ae44dcae78424b4638762d015cf24336444707f

This change adds a variable that can be used to disable kolla docker
registry login attempts, even when the registry username and password
are set.

This is required for deployments using a non-standard containerised
registry deployed on the seed during the deploy-container step,
since it takes place after the registry login attempt.

Change-Id: Ie17ef9ce1147cbaec2e42db932c7d59293b49b1b

This requires disabling libvirt_vm_trust_guest_rx_filters, which when
enabled triggers the following errors when booting baremetal instances
with Tenks on Libvirt 9 (and most likely since 8.9.0):

    Cannot set interface flags on 'macvtap1': Value too large for defined data type

This is apparently triggered by a Libvirt commit refreshing rx-filters
more often [1].

As explained in I71a2051d8acd63379bd70bc1287a059d4a7f6387, this setting
was added to allow traffic destined for other MAC addresses to reach VMs
when using a macvtap interface.

This will prevent multicast from working, but we don't need it for
baremetal tests in CI.

This setting will be enabled again once the issue is resolved in either
Libvirt or Tenks.

This reverts commit 21c68bbf.

Also increase timeout of upgrade jobs which is too short now due to the
added delay added by bare metal testing.

[1] https://gitlab.com/libvirt/libvirt/-/commit/060d4c83ef436cf56abfad51a4d64c39448e199d

Change-Id: I2cfd2667abb1ae8988b7a7fd9761b75c20a0eaa4

The importlib.metadata library is part of the Python standard library
since Python 3.8.

Change-Id: Iecf1d469caaa777c5b253eb0e44dc00692197ef7

Backports of I9dd5b97dec93c0e5393a1e7d9640f85003651b56 to stable
branches are failing CI checks because several unit tests mock
os.path.exists and would need to be updated. This does not affect master
because test code changed in I4d9f96ec4cf3c6cd0d28dfe5ddb239d863498a72.

Work around this issue by replacing os.path.exists by os.path.isfile. It
is a better check anyway since we are reading the file.

Change-Id: Ic53efd03cecbd53ad3e3b64b664e084f4e25be0e
Related-Bug: #2020135

The return value was set to the following path which is not valid:

    kayobe/kayobe/utils.py/..

The intent must have been to use dirname to produce:

    kayobe/kayobe/..

Change-Id: I9d7d71d42026f3c12da6de9c5ca55dc647554fd0

Using an editable installation of Kayobe fails on Rocky Linux 9 or
Ubuntu with an error such as:

    ERROR! The requirements file '/home/rocky/kayobe/kayobe/requirements.yml' does not exist.
    Failed to install Ansible roles from /home/rocky/kayobe/kayobe/utils.py/../requirements.yml via Ansible Galaxy: returncode 1
    Control host bootstrap failed - likely Ansible Galaxy flakiness. Sleeping 5 seconds before retrying

This is caused by recent changes to how pip manages editable
installations. The egg-link file that Kayobe was using to find the
source path does not exist anymore. Instead, there is a direct_url.json
file under the kayobe dist-info directory that can be parsed.

Change-Id: I9dd5b97dec93c0e5393a1e7d9640f85003651b56
Closes-Bug: #2020135