It appears that swift is occassionally responding to jobs with 404 when tempurls are used. Likely this is something to do with time, but the underlying credenital can also be validated. Since this works in newer branches, and no chanes can be attributed to swift, there is likely some sort of intermediate library issue where unable to pin down. In the interest of keeping a working CI, for now, mark the job as non-voting until we're able to figure something out. Change-Id: I46e8e8800eb1b08caba8faab6247195ea646430b
In case no BOM is present in the CSV file the utf-16 codec won't work.
We fail over to utf-16-le as Little Endian is commonly used.
NOTE: The original change landed this fix in efi_utils.py, however
that was introduced after the Xena development cycle, so this
backport moves the original change to where the code originally
came from to populate the efi_utils.py file.
Change-Id: I3e25ce4997f5dd3df87caba753daced65838f85a
(cherry picked from commit 697fa6f3b6db10408eaadd57450456de87f13519)
(cherry picked from commit 99b9d1403cacd3bbd489a6cf6913f32746ef6083)
Change-Id: I1e7a3b3c9ded13b10002bb47e98d4a7b486e1dd4
In the event a device name is set to contain a raid device path, it is possible for the Name and Events field values of mdadm's detailed output to contain text which inadvertently gets captured and mapped as component data for the "holder" devices of the RAID set. This would cause invalid values to get passed to UEFI methods which would cause a deployment to fail under these circumstances. We now ignore the Name and Events fields in mdadm output. Change-Id: If721dfe1caa5915326482969e55fbf4697538231 (cherry picked from commit f3e3de8097f05cc830768da7d3f3e9eae04b40a1) (cherry picked from commit 6660e01e1f8a6e7a40b798eea5215b1eddcbe0c3) (cherry picked from commit 5751f60353f3a4bf325a8c9335d743eec45fbcd1)
If present gather information about bonded interfaces. Story: #2010093 Task: #45637 Change-Id: I394187640b4788ebec21c3391d33ed728fb72ffa (cherry picked from commit 7e4fe3bf6a2ae41656b7923796f9c2d056a2ed04)
UDev prefix is DM_ not ID_ for them. On top of that, they don't have short serials (or at least don't always have). Change-Id: I5b6075fbff72201a2fd620f789978acceafc417b (cherry picked from commit 69e22545033f544d628f9c4ecd5a665ba0b5b85e)
Removes multipath base devices from consideration by default, and instead allows the device-mapper device managed by multipath to be picked up and utilized instead. In effect, allowing us to ignore standby paths *and* leverage multiple concurrent IO paths if so offered via ALUA. In reality, anyone who has previously built IPA with multipath tooling might not have encountered issues previously because they used Active/Active SAN storage environments. They would have worked because the IO lock would have been exchanged between controllers and paths. However, Active/Passive environments will block passive paths from access, ultimately preventing new locks from being established without proper negotiation. Ultimately requiring multipathing *and* the agent to be smart enough to know to disqualify underlying paths to backend storage volumes. An additional benefit of this is active/active MPIO devices will, as long as ``multipath`` is present inside the ramdisk, no longer possibly result in duplicate IO wipes occuring accross numerous devices. Story: #2010003 Task: #45108 Resolves: rhbz#2076622 Resolves: rhbz#2070519 Change-Id: I0fd6356f036d5ff17510fb838eaf418164cdfc92 (cherry picked from commit 014d37743a3b5694e0e2a3cabfafe885417172d5)