)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"60535c9fdfa5fee4252d2830029c9e0fd3b68d1c","unresolved":true,"context_lines":[{"line_number":12,"context_line":"the lifetime of that boot, and suspend to RAM is no way out on platforms"},{"line_number":13,"context_line":"implementing only s2idle. erase_devices is left with shred, which on a"},{"line_number":14,"context_line":"7.68 TB SSD takes many hours, consumes write cycles, and cannot reach"},{"line_number":15,"context_line":"remapped or over provisioned blocks behind the FTL anyway."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Discard is unaffected by either freeze. On a device which returns"},{"line_number":18,"context_line":"deterministic zeroes afterwards it is both faster and a better result than"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"16738ccb_99d6e7b8","line":15,"updated":"2026-08-25 17:37:03.000000000","message":"Please rewrite this long commit message with a human edit.\n\nAdditionally: please confirm directly for us that you have tested this change against real hardware and verified it does a proper deletion.","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"},{"author":{"_account_id":39388,"name":"Timon Schnell","display_name":"Timon Schnell","email":"timon.schnell@btc-it-services.com","username":"kingspeedy"},"change_message_id":"c7b82fad76b868541ed49ae785ff9e9cbf2bfe6f","unresolved":true,"context_lines":[{"line_number":12,"context_line":"the lifetime of that boot, and suspend to RAM is no way out on platforms"},{"line_number":13,"context_line":"implementing only s2idle. erase_devices is left with shred, which on a"},{"line_number":14,"context_line":"7.68 TB SSD takes many hours, consumes write cycles, and cannot reach"},{"line_number":15,"context_line":"remapped or over provisioned blocks behind the FTL anyway."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Discard is unaffected by either freeze. On a device which returns"},{"line_number":18,"context_line":"deterministic zeroes afterwards it is both faster and a better result than"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"8ef072f7_279d2495","line":15,"in_reply_to":"16738ccb_99d6e7b8","updated":"2026-08-31 18:49:17.000000000","message":"Rewritten and shortened.\n\nI tested the newest patch set directly on the hardware named in the bug. In our test environment we\nhave 20 nodes of type H13SRE-F, each with two Micron 5400 7.68 TB and two Samsung NVMe with 894 GB.\nThe two Micron show the freeze problem. The two Samsung do not, they erase normally with nvme-cli.\n\nThis is how we tested the erase:\n\n1. We built a ramdisk from this patch, and compared hardware.py inside it against the file in the\n   built image by hash, so we know the node really booted this code.\n2. Before the erase we wrote 7155 blocks of 4 KiB to each device, one per GiB over the whole\n   device. Each block contains its own offset, so we would notice if the device gave us data from\n   another position. All 7155 were read back first.\n3. Then erase_devices ran with the option on. 75.33 s and 75.16 s for the two devices in parallel,\n   against many hours for shred. BLKSECDISCARD is not supported on these drives and fails in 12 ms.\n4. After the erase all 7155 positions per device read back as zero. Then we read both devices\n   completely: all 7681501126656 bytes of each device are zero, in 32734 s and 32729 s at 235 MB/s.\n   The number of bytes read is the size of the device, and the counter for non zero bytes stayed at\n   0 the whole time.\n\nSo on this hardware nothing is left over.","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":39388,"name":"Timon Schnell","display_name":"Timon Schnell","email":"timon.schnell@btc-it-services.com","username":"kingspeedy"},"change_message_id":"4acb577e81ef97f1bd04787ffee95d6071d7cb7a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f8498e77_f2e1788e","updated":"2026-08-18 11:07:51.000000000","message":"Filed as https://bugs.launchpad.net/ironic-python-agent/+bug/2163748, RFE not approved yet, so this is up for feedback rather than for merging.\n\nTwo design questions are open and I would rather change the patch than defend it:\n\n1. Should the discard run automatically after secure erase fails, as here, or behind a new option? An option needs a companion change in ironic, since these flags reach the agent through driver_internal_info.\n2. Is the sampled verification sufficient, or should a secure discard be a hard requirement instead of merely preferred? These drives do not implement it.\n\nVerified on the affected hardware, both devices erased and verified in about 75 s each where shred needs hours. Details in the bug.","commit_id":"219e19e8c8ca1c169bfbecd68001f06a0e2366dd"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"4cd577e77186a008cbd3c0ff23403c1e11f11b58","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"15100357_679e1349","updated":"2026-08-19 15:55:52.000000000","message":"We need to evaluate https://bugs.launchpad.net/ironic-python-agent/+bug/2163748 and approve it at a team meeting before this moves forward. The next one is Monday at 8am PT in #openstack-ironic\n\nI think we should be VERY careful merging this as the failure case is \"disk wasn\u0027t erased\" which is about as major of a vuln as Ironic can have.","commit_id":"219e19e8c8ca1c169bfbecd68001f06a0e2366dd"},{"author":{"_account_id":36770,"name":"cid","display_name":"cid","email":"cid@gr-oss.io","username":"cidelight","status":"@gr-oss upstream: Doing good IRONIC things..."},"change_message_id":"0152c953211399ce9a39fda164635b1410f7a1f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5f7db14b_a0b12b30","updated":"2026-08-25 17:39:22.000000000","message":"GR-OSS group review. Looking good, please address the review comments. Thanks.","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"413a8c8826c3457185a2308e1e322028fc08050d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ee18a4e8_810459ad","updated":"2026-08-29 08:17:54.000000000","message":"recheck seems the ironic-standalone-ipa-src failure was unrelated","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"}],"doc/source/admin/troubleshooting.rst":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"60535c9fdfa5fee4252d2830029c9e0fd3b68d1c","unresolved":true,"context_lines":[{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Add ``ipa-enable-discard-erase\u003dTrue`` to the ``[pxe]kernel_append_params``"},{"line_number":279,"context_line":"parameter of ``ironic.conf``. In a multi-conductor deployment every"},{"line_number":280,"context_line":"``ironic.conf`` needs to match."},{"line_number":281,"context_line":""},{"line_number":282,"context_line":"Via Ramdisk configuration"},{"line_number":283,"context_line":"-------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"113c0435_aae4f814","line":280,"updated":"2026-08-25 17:37:03.000000000","message":"This will only impact things booted with pxe boot driver, and won\u0027t impact vmedia. It might be wiser just to provide a single example and a link to other documentation on how to set kernel parameters on a ramdisk.","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"},{"author":{"_account_id":39388,"name":"Timon Schnell","display_name":"Timon Schnell","email":"timon.schnell@btc-it-services.com","username":"kingspeedy"},"change_message_id":"c7b82fad76b868541ed49ae785ff9e9cbf2bfe6f","unresolved":true,"context_lines":[{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Add ``ipa-enable-discard-erase\u003dTrue`` to the ``[pxe]kernel_append_params``"},{"line_number":279,"context_line":"parameter of ``ironic.conf``. In a multi-conductor deployment every"},{"line_number":280,"context_line":"``ironic.conf`` needs to match."},{"line_number":281,"context_line":""},{"line_number":282,"context_line":"Via Ramdisk configuration"},{"line_number":283,"context_line":"-------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"969794c7_1bcc3154","line":280,"in_reply_to":"113c0435_aae4f814","updated":"2026-08-31 18:49:17.000000000","message":"I reduced it to one example and a link to the section above.\n\nI did not take the sentence about vmedia over, because we tested exactly that and got the opposite\nresult. We tested directly with the kernel parameter on the ramdisk, on a pod that has\nredfish-virtual-media as its only enabled boot interface. This is how:\n\n    baremetal node set \u003cnode\u003e \\\n      --driver-info kernel_append_params\u003d\u0027%default% ipa-enable-discard-erase\u003dTrue\u0027\n\nThe ramdisk then booted with:\n\n    BOOT_IMAGE\u003d/vmlinuz ... ipa-enable-discard-erase\u003dTrue ... boot_method\u003dvmedia --\n\nSo the option and boot_method\u003dvmedia are on the same command line, and the parameters from the\nconductor are still there because of %default%.\n\nThat fits the code. image_utils builds the command line of the deploy ISO with\ndriver_utils.get_kernel_append_params(node, default\u003dCONF.redfish.kernel_append_params), and that\nfunction reads instance_info, then driver_info, then the config. Only the default that the node\nlevel value replaces is specific to the boot interface, [pxe] or [redfish]. That is what the new\ntext says now.\n\nIf you want it worded differently, tell me and I will change it.","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"}],"ironic_python_agent/hardware.py":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"60535c9fdfa5fee4252d2830029c9e0fd3b68d1c","unresolved":true,"context_lines":[{"line_number":2053,"context_line":"            # shred handling below decides what happens, unchanged."},{"line_number":2054,"context_line":"            execute_discard_erase \u003d info.get(\u0027agent_enable_discard_erase\u0027,"},{"line_number":2055,"context_line":"                                             CONF.enable_discard_erase)"},{"line_number":2056,"context_line":"            if execute_discard_erase and self._discard_erase(block_device):"},{"line_number":2057,"context_line":"                # Log why secure erase was unavailable. Without this the"},{"line_number":2058,"context_line":"                # reason is lost whenever the discard succeeds, because the"},{"line_number":2059,"context_line":"                # only other places it is reported are the two shred"}],"source_content_type":"text/x-python","patch_set":3,"id":"28632082_020479b7","line":2056,"updated":"2026-08-25 17:37:03.000000000","message":"We need more informational logging here:\nYou should LOG (likely at INFO level) when:\n- Attempting a discard-style erase\n- When a discard-style erase fails (and ideally, we include the why: was blkdiscard missing/failed to execute? Did we fail verification of erase?)","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"},{"author":{"_account_id":39388,"name":"Timon Schnell","display_name":"Timon Schnell","email":"timon.schnell@btc-it-services.com","username":"kingspeedy"},"change_message_id":"c7b82fad76b868541ed49ae785ff9e9cbf2bfe6f","unresolved":true,"context_lines":[{"line_number":2053,"context_line":"            # shred handling below decides what happens, unchanged."},{"line_number":2054,"context_line":"            execute_discard_erase \u003d info.get(\u0027agent_enable_discard_erase\u0027,"},{"line_number":2055,"context_line":"                                             CONF.enable_discard_erase)"},{"line_number":2056,"context_line":"            if execute_discard_erase and self._discard_erase(block_device):"},{"line_number":2057,"context_line":"                # Log why secure erase was unavailable. Without this the"},{"line_number":2058,"context_line":"                # reason is lost whenever the discard succeeds, because the"},{"line_number":2059,"context_line":"                # only other places it is reported are the two shred"}],"source_content_type":"text/x-python","patch_set":3,"id":"7cb7cde1_84be2215","line":2056,"in_reply_to":"28632082_020479b7","updated":"2026-08-31 18:49:17.000000000","message":"Done, at INFO level, and every failure says why.\n\n_discard_erase now logs when it starts. Every exit gives a reason: the device reports no discard\nsupport, the device is too small to verify, the markers could not be written, neither a secure nor\na plain discard worked, or the sampled positions did not read back as zero. The blkdiscard errors\nkeep the command output, so you can see whether the tool was missing or the device refused. There\nis also a debug line at the call site when the option is off.\n\nA few examples from the run on the hardware:\n\n    INFO Attempting to erase /dev/sda by discarding it\n    INFO Attempting to erase /dev/sda by secure discard, discard_max_bytes is 2147450880\n    WARNING Could not secure discard /dev/sda, blkdiscard failed: Unexpected error while running\n            command. Command: blkdiscard --secure /dev/sda\n            Stderr: \u0027blkdiscard: BLKSECDISCARD: /dev/sda ioctl failed: Operation not supported\u0027\n    INFO Attempting to erase /dev/sda by discard, discard_max_bytes is 2147450880\n    INFO Verified 10 samples of /dev/sda as zeroed after the discard\n    INFO Device /dev/sda was erased by discarding it\n    INFO Erased /dev/sda by discarding it because secure erase was not available: Error erasing\n         block device: Block device /dev/sda is frozen and cannot be erased","commit_id":"ba02c518d77c4a63f4f39acf3fb43e34d4e9cb60"}]}