)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":39388,"name":"Timon Schnell","display_name":"Timon Schnell","email":"timonschnell22@googlemail.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"}]}