Depends-On: https://review.opendev.org/c/openstack/ironic/+/783722 Change-Id: I4905c17d2e78ed02e9005ffbd93b036674e6ff51
Follow-up to 8dd6589e66d03e45e1d510601da9531a30842cff: PATH is not a valid lsblk tag, we need to use KNAME with -p flag. Also add a vmedia job to avoid breakages in the future. It's added non-voting because we have a deadlock with this change: https://review.opendev.org/c/openstack/ironic/+/783722 Change-Id: Ifffeac9c1c4d394526d655eaa14c9fe7bd3a1e5e
Tinycore 12 requires some more RAM than its predecessor. Change-Id: I642ccdcef43361b5648a9652d041ebb6dfe6a0e9
As discussed during the upstream ironic community meeting on Monday Dec 14 2020, the lower-constraints job is being removed. Change-Id: Ide0f6c38a59ae6486fa33cfb19b383d022e57d5a
The ironic-ipa-base is based on ironic-base that is already running on ubuntu focal, non need to specify nodeset for those jobs that are based on it. Change-Id: I7ffb920442d5e33ef5014152b72b9ac32e367047
Also disabling dstat in all focal based jobs because of https://bugs.launchpad.net/ubuntu/+source/dstat/+bug/1866619 Plus including increase of alloc memory to increase job success rate, original change from [1] And re-enabling ipa-tempest-bios-ipmi-direct-src and ipa-tempest-bios-ipmi-iscsi-src [1] https://review.opendev.org/759765 Co-authored-by: Julia Kreger <juliaashleykreger@gmail.com> Change-Id: Ia154745b71c17063eeaaabeb56950ab1cc9ce927
The standalone job at present has a high chance of failure due to two separate things occuring: 1) The deployed nodes from raid tests can be left in a dirty state as the raid configuration remains and is chosen as the root device for the next deployment. IF this is chosen by any job, such as rescue or a deployment test that attempts to login, then the job fails with unable to ssh. The fix for this is in the ironic-tempest-plugin but we need to get other fixes into stablilize the gate first. https://review.opendev.org/#/c/757141/ 2) Long running scenarios run in cleaning such as deployment with RAID in the standalone suite can encounter conditions where the conductor tries to send the next command along before the present configuration command has completed. An example is downloading the image is still running, while a heartbeat has occured in the background and the conductor then seeks to perform a second action. This then causes the entire deployment to fail, even though it was transitory. This should be a relatively easy fix. https://review.opendev.org/759906 Also disabling ipa-tempest-bios-ipmi-direct-src and ipa-tempest-bios-ipmi-iscsi-src for the time being, will revert in https://review.opendev.org/757812 Change-Id: I08c8c258587dd3786dfa92e7879a80c80971d7df
By default, grub2-mkconfig scans everything to look for other environments and then load those into the grub configuration. It makes sense, but on newer versions of grub2 in distribution images, os-prober is taking an exceptionally long time in some cases where more than one storage device exists with other filesystems. As a result, of the os-prober execution by grub2-mkconfig, the bootloader installation can completely time out and fail the deployment. This is presently experienced with metalsmith on centos8. There are numerous sporatic reports of issues like this issue where grub2-mkconfig hangs for some period of time, and this is observable on Centos8.2 in our CI. While one report[0] mentions this issue, Another bug [1] has the dialog that actually helps us frame the context as to what we likely should do. Also, fixes the unit testing so we actually test if we're running with grub2. :\ [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1744693 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1709682 Depends-On: https://review.opendev.org/#/c/748315 Change-Id: I14bf299afef3a1ddb2006fe5f182d7f0d249e734
We can use focal here but we need to disable dstat because of https://bugs.launchpad.net/ubuntu/+source/dstat/+bug/1866619 Change-Id: I2c013e871fc56aa0077656dfc76de9aad6bed83f