Ironic has maintained a CI job for years after postresql support was
deprecated in order to prevent unintentional breakage of that support.
Now, we have confirmed evidence that other openstack components, such as
keystone, required for testing this postgresql support no longer
function in this job.
As a result, ironic can no longer test postgresql support. Operators
utilizing postgresql who have not yet migrated must migrate now.
Change-Id: If6e4432b000996789346a1f7449410cfc8497fe1
Trailing whitespace is soon to be caught by the global pre-commit
linter changes. This fixes this issue in anticipation of that lint.
Change-Id: I48597afde4c55775ccca56f927c30ca4f3465523
This adds a wsgi entrypoint module which can be used with a wsgi runner,
such as uwsgi, to launch Ironic API processes without the need of a
separate script.
The legacy WSGI script is currently being installed by PBR, and as part
of the migration to a pyproject.yaml-compatible PBR, we cannot use the
wsgi-scripts plugin anymore, and will be removing the script installed
by it in a future Ironic release.
The new WSGI script, because it has statements at the module top-level,
cannot be autodocumented; we now exclude it.
Also we don't treat all warnings as errors in pdf docs builds to allow
the use of mock autosummary, starting with including the wsgi module.
Co-Authored-By: Doug Goldstein <cardoe@cardoe.com>
Change-Id: I584ac6a25c4e6cd9744a609b50d12b434a930dc6
An interesting, and frustrating aspect of 4k block devices is that the math begins
to be impacted across the whole of the useage of the device.
Specifically the LVM block spacing also begins to be thrown
"out of alignment" which changes user calculations.
Most users doing smaller allocations likely won't matter, but users doing
thin volumes or filling the percentage of the remaining usable volume, also then
break.
So realistically, the best path to ensure we have appropriate 4k device testing,
and our dependent tooling in diskimage-builder is also getting tested, is to run
the more complex case in our CI job.
This change is dependent upon two other changes which are under review.
Change-Id: I5b23403c783fa84b4158708741524c3dc9a92722
grenade by default enable GLOBAL_VENV which means it
install and run everything from virtual env
- https://review.opendev.org/c/openstack/grenade/+/930507
We faced the error in ironic grenade scripts in virtual env
so GLOBAL_VENV was disabled explicitly. This fixing the scripts
and enable GLOBAL_VENV in ironic jobs also.
Change-Id: I48ee1dd4adc2e5bcc18c5f116d979e7524248495
No jobs are setting this, nor have any set it in some time. Remove it.
Change-Id: I38a092de125e382607d89d8e5a3b85db809a6d61
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Nothing is setting this anymore, making this a layer of indirection
we do not need. Remove it.
Change-Id: Iba3674536ee98ba4d2d0cb5ffb0ec52e5286b7e7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Add a CI job to leverage a 4k logical block disk image which is
deployed to the remote system to ensure the build pipeline and
code to naviate 4k disk images is in working order.
Change-Id: If7aee654f9282b33ea489558f45f45cfed86e9d1
Recently we became aware that some operators might need a larger
block size, but our CI testing doesn't represent any ability to
assert a different block size.
We can now assert a block size override in the scripting which
allows us to create a CI job.
Change-Id: I8470fb5b2827226dc155938a94c3a2cbe98912b5
This change makes it possible to test the new "agent" implementation.
The PXE environment is not migrated so far, so managed inspection is
assumed by default.
Change-Id: I60a11454aefc01333e3f788e2b09ec6e47423223
Right now, when restacking to get new code checked out, we fail due to
the dnsmasq directory already existing. Now, skip the downgrade if we
detect the correct version -- as we would on a second run.
Change-Id: I5c3d28f75b66d14540cbafa03bff8b7def688da5
In trying to chase down why the raw tftp boot of grub is not
happy, I determined that the tftp folder being created had the
wrong permissions out of the box. Ironic has an optional knob for
this, so we're going to set it by default.
Change-Id: If2a0e5e47163a3525ecd245e8b54cacea9a615de
This commit introduces support for provisioning ARM (aarch64)
fake-bare-metal VMs in Ironic for the purpose of eventually supporting
CI testing on ARM64 architecture-based hardware.
Change-Id: Ie4bff8892228275ad0fb940c30e8071f7f4c423f
There has been no testing of this hardware type in quite some time,
and the last we heard the vendor was moving towards redfish.
Change-Id: Ib32db463981ec54430884ac760956b7c7b40b17f
Codespell upgrade caused failures, fixed spelling where
appropriate, added ignores where appropriate.
Some new package release broke pep8 runs; fixed by no
longer pinning Pygments version.
Change-Id: I670bbb170823d6a0ace8eeb9d9e486e8e9bf7404
This makes all the image upload commands in the devstack plugin use
--file instead of stdin redirection, and also uses an absolute path.
One of the commands was already doing it this way. By doing the upload
like this, it makes the devstack plugin usable with the OCaaS devstack
mode (for faster openstack client ops) since we can't pass the image
stream via stdin. Most people will be using --file for uploading
anyway, so this is probably more realistic anyway.
Change-Id: I8d97ed731133d02aed46a078c50769692ad7ba04
Cirros partition images have some underlying limitations,
meaning it is not ideal for any step which requires the image
to hae commands executed in it to perform operations, such as
mounting additional filesystems in UEFI mode, or installing
grub in BIOS mode.
This is because cirros images are an unpacked ramdisk, in other
words, the posted disk image *has no* contents on the root
filesystem of the image. While we attempt to unpack[0] this as well,
this can also fail creating false failures resulting in check
jobs failing and then working on recheck.
As the constraint is the same as the BIOS mode check, and there
is no realistic fix, this change removes the boot mode check and
thus always disables partition image testing with tempest *when*
cirros is in use.
note 0: We presently unpack using a virtual machine launch so it
takes place with the same process as when cirros starts, however
linux doesn't always boot, and the tools don't really determine
if that is the case or not, and if we retool it, we should just
move to a direct extraction and image re-pack.
Change-Id: I7687ff1eddb14d22b981860d4c4c9b172bae45b7
Had someone try to boot the tinycore ISO on a UEFI machine, and they
got a nice error. Just turns out we needed to update our docs a little
bit to provide appropriate clarity.
Change-Id: I1adfb62ea22d0b58740ceadc8c338fc04d9b78de
Cirros, by default, as part of its initialization, copies the initial
ramdisk contents over the filesystem on disk. This changes the partition
image creation job so we do it upfront so the partition image looks like
and matches what we generally expect from a partition image as opposed
to just a kernel, ramdisk, and bootloader.
Change-Id: Idde30e33e9453f8564a7c3b9109c4e567146dee7
``redfish_system_id`` is being passed multiple times to the node at
creation as ``node_options`` never defaults back to it's initial state
throughout the iteration of the while loop.
Though it is surprisingly functional, it's fragile and this change aims
to fix that.
Closes-Bug: #2054597
Change-Id: I2c151afafb86191f047985ac00075a791639646d
A temporary path forward to increase CI stability, by pinning
to what appears to be a "good working version" of upstream dnsmasq
which does not crash fon us.
Change-Id: I3295c92fd7b7871ad351b94f4c6cf0f554279db0
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
Extension to extend the default service project name
value, which if set can be overrridden in Ironic's policy
configuration.
Change-Id: I60cc53a34c7062261703492e720989efedca4f2b
When I thought change I2b4bcc748b6e43e4215dc45137becce301349032
was going to fix everything, that was with the mental model that
it was going to be enabled by default. That didn't happen in
review as part of the service, but the reality is we still have
some adjacent CI jobs which need it to operate properly.
Given CI, it is just invoked when scope enforcement is enabled
for CI purposes
Change-Id: I60074504742d8b09017acbb42d2706215b0169af
