delta/openstack/ironic-python-agent.git/ironic_python_agent/tests/unit/samples, branch 8.2.2 opendev.org: openstack/ironic-python-agent.git Fix software raid output poisoning 2022-09-16T21:32:06+00:00 Julia Kreger juliaashleykreger@gmail.com 2022-08-24T17:15:27+00:00 8d033aa4e551cc3974448aca77147a339c749ecc 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) 
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)
Multipath Hardware path handling 2022-06-09T13:21:27+00:00 Julia Kreger juliaashleykreger@gmail.com 2022-04-07T22:15:17+00:00 faf2ee2df8ddf3cba80eaa8acbd8b0cf0225ee10 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) 
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)
Do not try to guess EFI partition path by its number 2022-05-06T12:57:00+00:00 Dmitry Tantsur dtantsur@protonmail.com 2022-05-04T12:45:33+00:00 067cf9b535b5c93343c73fa476e6dde51d9c711f The logic of adding a partition number to the device path does not work for devicemapper devices (e.g. a multipath storage device). Conflicts: ironic_python_agent/efi_utils.py ironic_python_agent/tests/unit/extensions/test_image.py ironic_python_agent/tests/unit/test_efi_utils.py Change-Id: I9a445e847d282c50adfa4bad5e7136776861005d (cherry picked from commit f09f6c9f1a09c7062d0450b3e0a4d3164fd53f7f) 
The logic of adding a partition number to the device path does not work
for devicemapper devices (e.g. a multipath storage device).

Conflicts:
	ironic_python_agent/efi_utils.py
	ironic_python_agent/tests/unit/extensions/test_image.py
	ironic_python_agent/tests/unit/test_efi_utils.py

Change-Id: I9a445e847d282c50adfa4bad5e7136776861005d
(cherry picked from commit f09f6c9f1a09c7062d0450b3e0a4d3164fd53f7f)
Create fstab entry with appropriate label 2022-03-11T01:15:33+00:00 Julia Kreger juliaashleykreger@gmail.com 2022-02-25T20:18:39+00:00 c69ea032fe8ab81e459fb44f846f440e7a2c8922 Depending on the how the stars align with partition images being written to a remote system, we *may* end up with *either* a Partition UUID value, or a Partition's UUID value. Which are distinctly different. This is becasue the value, when collected as a result of writing an image to disk *falls* back and passes the value to enable partition discovery and matching. Later on, when we realized we ought to create an fstab entry, we blindly re-used the value thinking it was, indeed, always a Partition's UUID and not the Partition UUID. Obviously, the label type is quite explicit, either UUID or PARTUUID respectively, when initial ramdisk utilities such as dracut are searching and mounting filesystems. Adds capability to identify the correct label to utilize based upon the current state of the block devices on disk. Granted, we are likely only exposed to this because of IO race conditions under high concurrecy load operations. Normally this would only be seen on test VMs, but systems being backed by a Storage Area Network *can* exibit the same IO race conditions as virtual machines. Change-Id: I953c936cbf8fad889108cbf4e50b1a15f511b38c Resolves: rhbz#2058717 Story: #2009881 Task: 44623 (cherry picked from commit 99ca1086dbfc7b6e41cf800b0bd899565e2e8922) 
Depending on the how the stars align with partition images
being written to a remote system, we *may* end up with
*either* a Partition UUID value, or a Partition's UUID value.

Which are distinctly different.

This is becasue the value, when collected as a result of writing
an image to disk *falls* back and passes the value to enable
partition discovery and matching.

Later on, when we realized we ought to create an fstab entry,
we blindly re-used the value thinking it was, indeed, always
a Partition's UUID and not the Partition UUID. Obviously,
the label type is quite explicit, either UUID or PARTUUID
respectively, when initial ramdisk utilities such as dracut
are searching and mounting filesystems.

Adds capability to identify the correct label to utilize
based upon the current state of the block devices on disk.

Granted, we are likely only exposed to this because of IO
race conditions under high concurrecy load operations.
Normally this would only be seen on test VMs, but
systems being backed by a Storage Area Network *can*
exibit the same IO race conditions as virtual machines.

Change-Id: I953c936cbf8fad889108cbf4e50b1a15f511b38c
Resolves: rhbz#2058717
Story: #2009881
Task: 44623
(cherry picked from commit 99ca1086dbfc7b6e41cf800b0bd899565e2e8922)
Fix getting memory size in some lshw output 2021-04-29T18:41:11+00:00 Zane Bitter zbitter@redhat.com 2021-04-28T16:26:43+00:00 ed791d97786f4ed37bf7b9f18eac8e2af46c3766 Due to a regression in lshw introduced by https://github.com/lyonel/lshw/pull/60, there are some versions in the wild that do not return sizes for memory banks <32GiB. In those cases, work around the problem by looking at the top-level size (if available) to find the total size. Previously we assumed that we only needed the top-level size when there was no list of memory banks. The issue is fixed upstream by https://github.com/lyonel/lshw/pull/65, but the erroneous patch is still present in the lshw-B.02.19.2-5.el8 package in CentOS 8.4 and 8.5. Change-Id: I6eb5981d28b9ae368239af0c1d0ec32ff79d95b3 Story: #2008865 Task: 42395 
Due to a regression in lshw introduced by
https://github.com/lyonel/lshw/pull/60, there are some versions in the
wild that do not return sizes for memory banks <32GiB. In those cases,
work around the problem by looking at the top-level size (if available)
to find the total size. Previously we assumed that we only needed the
top-level size when there was no list of memory banks.

The issue is fixed upstream by https://github.com/lyonel/lshw/pull/65,
but the erroneous patch is still present in the lshw-B.02.19.2-5.el8
package in CentOS 8.4 and 8.5.

Change-Id: I6eb5981d28b9ae368239af0c1d0ec32ff79d95b3
Story: #2008865
Task: 42395
Allow clean_configuration to run against full-device arrays 2021-02-27T22:24:16+00:00 Mohammed Naser mnaser@vexxhost.com 2021-02-27T02:42:18+00:00 ab267aabdd84e4cdf6496ec3a11fcb3580d542bd At the moment, it is not possible for Ironic to clean up a RAID array that is built from an entire device. This patch allows it to do so by overriding the behaviour of attempting to find the device name if the device names does not end with a number and is a real block device. Story: #2008663 Task: #41948 Change-Id: I66b0990acaec45b1635795563987b99f9fa04ac7 
At the moment, it is not possible for Ironic to clean up a
RAID array that is built from an entire device.  This patch
allows it to do so by overriding the behaviour of attempting
to find the device name if the device names does not end with
a number and is a real block device.

Story: #2008663
Task: #41948
Change-Id: I66b0990acaec45b1635795563987b99f9fa04ac7
Add support for using NVMe specific cleaning 2021-02-18T12:51:34+00:00 Jacob Anders janders@redhat.com 2021-01-22T00:20:15+00:00 8bcf1be9200b52536f76cb61c62071eaaac1e004 This change adds support for utilising NVMe specific cleaning tools on supported devices. This will remove the neccessity of using shred to securely delete the contents of a NVMe drive and enable using nvme-cli tools instead, improving cleaning performance and reducing wear on the device. Story: 2008290 Task: 41168 Change-Id: I2f63db9b739e53699bd5f164b79640927bf757d7 
This change adds support for utilising NVMe specific cleaning tools
on supported devices. This will remove the neccessity of using shred to
securely delete the contents of a NVMe drive and enable using nvme-cli
tools instead, improving cleaning performance and reducing wear on the device.

Story: 2008290
Task: 41168
Change-Id: I2f63db9b739e53699bd5f164b79640927bf757d7
Remove samples from the hardware test module 2021-02-12T13:48:37+00:00 Riccardo Pittau elfosardo@gmail.com 2021-02-11T14:36:09+00:00 a35761c21fa8ad7856723b0ec68ddc87db39c709 They take a lot of space and tehy're mainly static data. Move them to a separate module that can also be shared with other tests. Change-Id: I9c76c014430d524da7fa331c922976d283b870c3 
They take a lot of space and tehy're mainly static data.
Move them to a separate module that can also be shared with other tests.

Change-Id: I9c76c014430d524da7fa331c922976d283b870c3