Changing the ironic-tempest-uefi-redfish-vmedia and
ironic-tempest-ovn-uefi-ipmi-pxe jobs to only run
tempest test_baremetal_server_ops_wholedisk_image.
We saw failures on the partition tests for this jobs.
Related-Bug: #2057972
Change-Id: I2e26d7955ade11046bf89b6f4c9c2c4f16da1574
Adds a job which utilizes the redfish-https boot mechanism
code which recently landed in ironic, which operates similar
to virtual media
Change-Id: Iad55a263ed34e6b121495b72a3c79449d7471901
* Adds httpboot enabled CI
Sets the interfaces to be enabled on the standalone job
in anticipation for standalone job support for these
interfaces[0] and switches the boot from volume
job over to utilize httpboot by default.
* Phases out now-redundant ironic-standalone job
The ironic-standalone job does all the same work as the
ironic-standalone-redfish job, and IPMI CI jobs are covering
IPMI cases. So we don't need this anymore.
Also makes a note on another redfish job which is likely
redundant as well, although does not yet remove it.
* Fix IPMI Partition Job name
This is more of a test of OVN than of partition specifically,
in fact, it runs both wholedisk and partition jobs already. Make
the name more sensible.
[0]: https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/902171
Co-Authored-By: Julia Kreger <juliaashleykreger@gmail.com>
Change-Id: I6c41b8f124e2e1fbc314243bf821153d79e2e09b
DNSMasq is not cooperating with us; it's respawning frequently.
Temporarily make these non-voting while we troubleshoot.
Change-Id: I0dcb09f31254d81d3a5ec9a52304bab93901e8f6
dnsmasq-2.86 shipped in Ubuntu jammy has a
known issue[1] which is fixed in dnsmasq-2.87
but it's not yet released with Ubuntu jammy.
Until fixed version is available in Ubuntu
jammy let's use source install instead of
using a older version from Ubuntu focal.
[1] https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q3/016562.html
Update from Julia:
Pushing forward the source fix again as ubuntu removed the
prior path we were using as a focal package and replaced
it with a package which is demonstrating the same basic issue.
Related-Bug: #2026757
Change-Id: I7ffcd167fc1e3a8c1192d766743bb5620d85ef35
Third in a series of commits to add Codespell to Ironic Repos. This commit adds the Tox Target to CI
A future commit could potentially add a git-blame-ignore-revs file if their are lots of spelling mistakes that could clutter git blame.
Change-Id: I82239bd5ca1b184e36c63d08413362c76fa8d4b4
The following services were removed some time ago.
- nova-objectstore
- nova-consoleauth
- glance-registry
Change-Id: I3a577c44abe46fc6cb146f3540bded1c5cb4a511
Change the default RBAC policy in ironic such that the new RBAC
policy is enforced by default and the legacy policy is not usable
unless explicitly re-enabled.
Depends-On: https://review.opendev.org/c/openstack/metalsmith/+/905012
Change-Id: Id559f1d8b9a76c8a570b598585c2d58c56d08837
The host currently hard-coded is not functioning. This replaces
the hard-coded mirror by the local CI mirror detected. In case
mirror info is not available then upstream centos mirror is used.
Change-Id: I96a8cb45154c9dbb50efecc22d34c4ff75c6722a
The standalone job has not passed on the master branch in a
very long time. I stopped looking at the history as of August 2023,
but it was only passing on Xena and Wallaby stable branches.
A few things to note:
* It appears to be intended to exercise inspector as a WSGI app,
and loads quite a bit of different configuration.
* Overall, it is failing due to the image it is trying to use
(cirros) which doesn't support setting a bootloader up, but
that is sort of required.
* Job is configured to netboot a node for an OS on the disk,
but that is not something ironic does really anymore. Quite
possibly, that is why the job is failing.
* Inspector, as a non-integrated thing, is on the path of
deprecation at this point, so we don't really need to focus
on this specific case anymore.
Overall, it seems like a job we should have just removed some
time ago. So... doing so.
Change-Id: I3aca63c183af863d9db1f27a4cfe0d6495bb03c2
Bandit 1.7.5 introduced some changes which broke the bandit job,
which caused the job to fail ages ago. We've since fixed those.
But, moving forward we need to fix these relatively quickly when
they occur, as such changing the test to voting improves our overall
security posture by forcing us to address these as they occur.
Change-Id: I4a7954bfd20eafdb578896e1f61204edc7f9ec7e
Two jobs are changed to test a reduced Redfish implementation:
one PXE job uses the minimum version (only boot/power management)
one vmedia job uses the reduced version (+ NICs, virtual media)
Change-Id: Ib3afdb26b9cd36c0e4f3d736b9c69a5bf508fc0e
tl;dr, devstack no longer supports focal, and now errors which
results in the job failing.
Also changes the snmp job to utilize the test_ramdisk_iso
feature, as *opposed* to a full deployment because iPXE
shipped with Ubuntu no longer likes to chain boot in UEFI
mode to a block device. The easiest path, is just to run
a ramdisk in that case, which also sort of mirrors what
users of the SNMP power interface *tend* to do.
Related-Bug: #2034588
Change-Id: I276885b8f0492ead8cea38fe13826123131984ea
Some of the object unit tests grub Mock object unintentionally, and
that results in failure during initializing an versioned object,
because the Mock object does not present its version correctly.
This fixes that problem.
The sqlalchemy-2x job is made non-voting because this job requires
oslo.utils 6.3.0 which is blocked by this problem.
Closes-Bug: #2043116
Related-Bug: #2042886
Change-Id: I1a622ab9c766d46b7eb4442848e91f25b26f6c61
Adds basic testing for PXE/iPXE boot secenarios where the OVN
DHCP service is used instead of dnsmasq.
Also adds a release note and documentation to cover the details
and caveats of using ovn as we have discovered through this process.
Change-Id: I28cd20a7f271220d8ca335895ca9e302452fd069
Ubuntu focal was in testing runtime as best effort
testing in 2023.1 cycle. In 2023.2, we do not need to
test the focal as such. Removing its testing to more
focus on making Jammy testing more stable.
[0] https://review.opendev.org/c/openstack/tempest/+/884952
Change-Id: Ia3a9bfb6287fd283c3eeb49b43d2c0d12420596d
Two issues have occcured:
1) Zuul has decided some syntax is deprecated and generates an error.
The exlcusionary nature of the syntax is just not supported by RE2
which is the new requirement, so explicitly matching "^master$"
as opposed to "not stable branches".
2) Marking the snmp job as non-voting, the root issue appears to be ipxe
or the VMs, unknown as of yet.
Change-Id: I68aa95eb1ed80a0fde1c29d708ebd606393481aa
Investigation of our standalone test job issues, where jobs would
fail, hosts not get DHCP updates, and ultimately IPXE would
fail prior to getting a valid or the expected response,
revealed the discovery that dnsmasq was crashing often when
the port updates were going through, ultimately preventing
the mutli-scenario test jobs from running as the standalone
jobs represent a number of different scenarios which are
executed across a pool of test machines.
In this case, the path forward appears to be to downgrade
dnsmasq to stablize our CI and allow us to otherwise upgrade.
This patch adds the focal updates as a package source,
and installs the dnsmasq package.
Related-Bug: #2026757
Change-Id: Iacfd1ab677c612525601afcaeee5e5b067206ff3
All database migration testing in opestack is done through
an opportunistic worker model, where if the database is available
and correctly configured for testing, i.e. openstack-citest user
and access appropriately granted, then the tests will create and
test migrations.
However, this has been problematic with mysql as of recent, as we
have seen a long standing migration issue boil to the surface often
with tests.
As a result, we're isolating that test down to it's own job so we
can limit the blast damage. This also helps us isolate is it all
of the tests, or is it just soley isolated down to the mysql test
run class, which is an additional data point.
By default, we continue to run Postgres migration tests in the
main jobs, as they haven't been impacted by this issue.
Change-Id: Iefc044c31ef029e400a7dad294504175a4462638
Leave the snmp job on focal for the time being as it's failing on jammy
and we need to move forward with the migration.
Change-Id: I0b9b600c3eb10761054abdb9c13d7107269001b9
Now that we have autocommit disabled, we need to make the metal3 job
voting to ensure we don't accidentally break sqlite support in the
future.
Change-Id: I4915dc23b1101b9b799f392434f237e5ccb323e4
It appear the push to Cirros 0.6.1 has re-occured, and we now
have things failing as a result.
Specifically ironic-grenade is trying to run with Cirros 0.5.2,
yet the file is not found later on.
Anyhow, an explicit pin should resolve this.
Change-Id: I97a1403820c8dbe633cf1d529adc79e8af463e80
Disabling the performance counters as we suspect it is causing
database interaction to freeze on the grenade CI job.
Change-Id: Id951815ab9bfd1ca16aa66fa4c87c0e1b3e788f6
In the recent change to cinder, to address CVE-2023-2088,
cinder changed the policy rules and behavior for unbinding,
or "detaching" a volume. This was because of a vulnerability
in compute nodes where a volume which was in use by a VM
could be detached outside of Nova, and nova wouldn't become
aware the volume was detached, and the volume could be accessible
to the next VM.
This vulnerability doesn't apply to bare metal operations as
volumes are attached to whole baremetal nodes with Ironic.
We now generate and use a service token when interacting with
Cinder which allows cinder to recognize "this request is
coming from a fellow OpenStack service", and by-pass
checking with Nova if the "instance" is managed by Nova,
or Not. This allows the volumes to be attached, and detached
as needed as part of the power operation flow and overall
set of lifecycle operations.
Related-Bug: 2004555
Closes-Bug: 2019892
Change-Id: Ib258bc9650496da989fc93b759b112d279c8b217
Until we're able to get the BFV job softed, we need to unblock
the gate, and as such moving the BFV job to non-voting to allow
other contributors to make progress.
Change-Id: I045d58afe195f08823af3b1a2fa6eabb6efb63ca