delta/openstack/ironic-python-agent.git/ironic_python_agent/hardware.py, 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)
Gather details about bond interfaces if present 2022-07-13T12:30:32+00:00 Derek Higgins derekh@redhat.com 2022-06-16T13:59:07+00:00 8c576f14eb688323bf241800d2eae28278991c02 If present gather information about bonded interfaces. Story: #2010093 Task: #45637 Change-Id: I394187640b4788ebec21c3391d33ed728fb72ffa (cherry picked from commit 7e4fe3bf6a2ae41656b7923796f9c2d056a2ed04) 
If present gather information about bonded interfaces.

Story: #2010093
Task: #45637

Change-Id: I394187640b4788ebec21c3391d33ed728fb72ffa
(cherry picked from commit 7e4fe3bf6a2ae41656b7923796f9c2d056a2ed04)
Fix discovering WWN/serial for devicemapper devices 2022-06-22T13:59:55+00:00 Dmitry Tantsur dtantsur@protonmail.com 2022-06-14T17:06:53+00:00 aeea61fce5c07d52acfb9bef35f0730adb639808 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) 
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)
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)
SoftwareRAID: Use efibootmgr (and drop grub2-install) 2022-03-16T13:59:08+00:00 Arne Wiebalck Arne.Wiebalck@cern.ch 2022-01-24T14:00:05+00:00 aeed2df155105384bda377d2dba32726b87b026a Move the software RAID code path from grub2-install to efibootmgr: - remove the UEFI efibootmgr exception for software RAID - create and populate the ESPs on the holder disks - update the NVRAM with all ESPs (the component devices of the ESP mirror, use unique labels to avoid unintentional deduplication of entries in the NVRAM) In addition, use canonical device names for the RAID device for the ESP: it seems like tinyIPA silently replaces /dev/md/esp with /dev/md127. Find the next free /dev/md device and use it instead. Also rescan the resulting device before copying files. Co-authored-by: Dmitry Tantsur <dtantsur@protonmail.com> Story: #2009794 Change-Id: I7ed34e595215194a589c2f1cd0b39ff0336da8f1 (cherry picked from commit 62c5674a600baeeef0af3b12baeab486870eb103) 
Move the software RAID code path from grub2-install to
efibootmgr:

- remove the UEFI efibootmgr exception for software RAID
- create and populate the ESPs on the holder disks
- update the NVRAM with all ESPs (the component devices
  of the ESP mirror, use unique labels to avoid unintentional
  deduplication of entries in the NVRAM)

In addition, use canonical device names for the RAID device for
the ESP: it seems like tinyIPA silently replaces /dev/md/esp
with /dev/md127. Find the next free /dev/md device and use it
instead. Also rescan the resulting device before copying files.

Co-authored-by: Dmitry Tantsur <dtantsur@protonmail.com>

Story: #2009794

Change-Id: I7ed34e595215194a589c2f1cd0b39ff0336da8f1
(cherry picked from commit 62c5674a600baeeef0af3b12baeab486870eb103)
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)
Re-read the partition table with partx -a, part 2 2021-11-10T19:53:02+00:00 Riccardo Pittau elfosardo@gmail.com 2021-11-09T11:50:46+00:00 ede08470221abedda823b200f4adcc9532a2b59b Use add instead of update to re-read the partition table with partx. See [1] for more details. Co-authored-by: Arne Wiebalck <arne.wiebalck@cern.ch> [1] https: //opendev.org/openstack/ironic-python-agent/commit/dc8c1f16f9a00e2bff21612d1a9cf0ea0f3addf0 Change-Id: I2336e22dadc790cfbde87904612fcaa3b8c501db (cherry picked from commit 23e67b5fea58295d0320f99d4513a66d720f09ee) 
Use add instead of update to re-read the partition table with partx.

See [1] for more details.

Co-authored-by: Arne Wiebalck <arne.wiebalck@cern.ch>

[1] https: //opendev.org/openstack/ironic-python-agent/commit/dc8c1f16f9a00e2bff21612d1a9cf0ea0f3addf0

Change-Id: I2336e22dadc790cfbde87904612fcaa3b8c501db
(cherry picked from commit 23e67b5fea58295d0320f99d4513a66d720f09ee)
Software RAID: Call udev_settle before creation 2021-10-06T16:24:35+00:00 Arne Wiebalck Arne.Wiebalck@cern.ch 2021-10-04T14:57:56+00:00 a0c55b917bb4ecabd75cbdb3224187a09c427500 This patch fixes a race during software RAID creation: we create the partition with parted, the kernel then notifies udev, but we need to wait for udevd to create the device files before calling mdadm to create the md device. Credits to jcosmao for finding this. Change-Id: I642f28acc351cf50263e37dfbc8468bf59de2cc5 (cherry picked from commit 9d707e9f4bab40109b7e29df2136e86d65325ea3) 
This patch fixes a race during software RAID creation:
we create the partition with parted, the kernel then
notifies udev, but we need to wait for udevd to create
the device files before calling mdadm to create the
md device.

Credits to jcosmao for finding this.

Change-Id: I642f28acc351cf50263e37dfbc8468bf59de2cc5
(cherry picked from commit 9d707e9f4bab40109b7e29df2136e86d65325ea3)
Trivial: better debugging in list_all_block_devices 2021-08-27T10:19:28+00:00 Dmitry Tantsur dtantsur@protonmail.com 2021-08-27T10:19:23+00:00 07ff3b8bbc8c043ba1469aba1147bba81f8997ee One debug message only specified "Skipping" without any details. Another did not log the whole line from lsblk. Fix both. Change-Id: I9f8f4edad88ba2df5abc6a45a74ebdb3c7afcf97 
One debug message only specified "Skipping" without any details.
Another did not log the whole line from lsblk. Fix both.

Change-Id: I9f8f4edad88ba2df5abc6a45a74ebdb3c7afcf97
Merge "Move loading of IPMI module loading to a single point" 2021-08-23T16:14:14+00:00 Zuul zuul@review.opendev.org 2021-08-23T16:14:14+00:00 438a1f44451ce3902971137e1a0427cd89897783