)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":12393,"name":"chandan kumar","display_name":"Chandan Kumar","email":"chkumar@redhat.com","username":"chkumar246"},"change_message_id":"16d3c22daf73e2b600061de0ecf87e3d10802392","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":18,"id":"57ff9926_53cca5cd","updated":"2026-08-18 12:01:14.000000000","message":"Docs needs restructuring.","commit_id":"4ac62f0cae017da2ae9fea4c42437277049b49d9"}],"api-ref/source/devices.inc":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"cfb0e7579eff1514b6b6c47032d33c46003be061","unresolved":false,"context_lines":[{"line_number":42,"context_line":"  - vendor_board_info: device_vendor_board_info_resp"},{"line_number":43,"context_line":"  - hostname: hostname_resp"},{"line_number":44,"context_line":"  - status: device_status_resp"},{"line_number":45,"context_line":"  - device_state: device_state_resp"},{"line_number":46,"context_line":"  - created_at: created"},{"line_number":47,"context_line":"  - updated_at: updated"},{"line_number":48,"context_line":"  - links: links"}],"source_content_type":"text/x-c++src","patch_set":2,"id":"cbea3e0a_1edc201f","line":45,"updated":"2026-08-06 11:49:17.000000000","message":"The API reference for the List Devices endpoint was updated to include device_state in the response parameters, but the corresponding example JSON sample (devices-list-resp.json) was not updated to include the new field, creating an inconsistency between documented response schema and example out...\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: The API reference and example output are inconsistent for the List Devices endpoint, which may confuse API consumers. The get-one example was correctly updated but the list example was overlooked.\n\n**Recommendation**:\nAdd \u0027\"device_state\": \"available\"\u0027 to the device object in doc/api_samples/devices/devices-list-resp.json, matching the format used in devices-getone-resp.json.","commit_id":"57bb4b8bd69d542850f795a49fe4cd4fb10e2b78"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"cfb0e7579eff1514b6b6c47032d33c46003be061","unresolved":false,"context_lines":[{"line_number":138,"context_line":""},{"line_number":139,"context_line":".. rest_method:: POST /v2/devices/{device_uuid}/clean"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Trigger data cleanup on a device. The device must support cleaning"},{"line_number":142,"context_line":"(currently NVMe devices only) and must be in ``error`` or"},{"line_number":143,"context_line":"``pending_cleaning`` state. Returns ``202 Accepted`` and cleanup"},{"line_number":144,"context_line":"proceeds asynchronously."}],"source_content_type":"text/x-c++src","patch_set":2,"id":"3c1ad216_c2600df9","line":141,"updated":"2026-08-06 11:49:17.000000000","message":"The POST /v2/devices/{device_uuid}/clean API reference states the device must be in \u0027error\u0027 or \u0027pending_cleaning\u0027 state, but the actual implementation rejects pending_cleaning with a 409 Conflict response. Only devices in \u0027error\u0027 state are accepted.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: Operators following the API reference will attempt to trigger cleanup on devices in pending_cleaning state and receive an unexpected 409 Conflict error. This creates confusion and erodes trust in the documentation.\n\n**Priority**: Before merge\n**Why This Matters**: Operators following the API reference will attempt to trigger cleanup on devices in pending_cleaning state and receive an unexpected 409 Conflict error. This creates confusion and erodes trust in the documentation.\n\n**Recommendation**:\nChange the API reference text from \u0027must be in ``error`` or ``pending_cleaning`` state\u0027 to \u0027must be in ``error`` state\u0027. Alternatively, if pending_cleaning should be acceptable, that would require a code change, but the current code clearly rejects it.","commit_id":"57bb4b8bd69d542850f795a49fe4cd4fb10e2b78"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"96df2cc543ff8319559e86212a9c6e3972cf5bf0","unresolved":false,"context_lines":[{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Trigger data cleanup on a device. The device must support cleaning"},{"line_number":142,"context_line":"(currently NVMe devices only) and must be in ``error`` or"},{"line_number":143,"context_line":"``pending_cleaning`` state. Returns ``202 Accepted`` and cleanup"},{"line_number":144,"context_line":"proceeds asynchronously."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":".. note::"}],"source_content_type":"text/x-c++src","patch_set":6,"id":"cb61f830_253f31a5","line":143,"updated":"2026-08-07 08:09:54.000000000","message":"The API reference for POST /v2/devices/{device_uuid}/clean states the device \u0027must be in error or pending_cleaning state\u0027, but the actual implementation only accepts devices in the error state. A device in pending_cleaning will receive a 409 Conflict.\n\n**Severity**: HIGH | **Confidence**: 1.0\n\n**Risk**: API consumers who read the reference and attempt to call POST /clean on a device in pending_cleaning state will receive an unexpected 409 Conflict. This could cause integration failures and wasted debugging time for operators and SDK developers.\n\n**Priority**: Before merge\n**Why This Matters**: API consumers who read the reference and attempt to call POST /clean on a device in pending_cleaning state will receive an unexpected 409 Conflict. This could cause integration failures and wasted debugging time for operators and SDK developers.\n\n**Recommendation**:\nRemove \u0027or pending_cleaning\u0027 from the description so it reads: \u0027The device must support cleaning (currently NVMe devices only) and must be in error state.\u0027 Alternatively, if accepting pending_cleaning is the intended behavior, fix the controller code to also accept that state.","commit_id":"b2c5109ed500b8b76ace36b0da4594efcc74ce49"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d6708321055c84a5516741e0d986ccfdd12e6ff0","unresolved":false,"context_lines":[{"line_number":139,"context_line":".. rest_method:: POST /v2/devices/{device_uuid}/clean"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Trigger data cleanup on a device. The device must support cleaning"},{"line_number":142,"context_line":"(currently NVMe devices only) and must be in ``error`` or"},{"line_number":143,"context_line":"``pending_cleaning`` state. Returns ``202 Accepted`` and cleanup"},{"line_number":144,"context_line":"proceeds asynchronously."},{"line_number":145,"context_line":""}],"source_content_type":"text/x-c++src","patch_set":7,"id":"7cde532c_694a4a4e","line":142,"updated":"2026-08-07 17:23:23.000000000","message":"The new POST /v2/devices/{device_uuid}/clean API reference states the device must be in \u0027error\u0027 or \u0027pending_cleaning\u0027 state, but the actual implementation only accepts the \u0027error\u0027 state and returns HTTP 409 Conflict for any other state.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: API consumers who attempt to call POST /clean on a device in \u0027pending_cleaning\u0027 state based on this documentation will receive an unexpected HTTP 409 Conflict response, causing integration failures and eroding trust in the API reference.\n\n**Priority**: Before merge\n**Why This Matters**: API consumers who attempt to call POST /clean on a device in \u0027pending_cleaning\u0027 state based on this documentation will receive an unexpected HTTP 409 Conflict response, causing integration failures and eroding trust in the API reference.\n\n**Recommendation**:\nRemove \u0027or ``pending_cleaning``\u0027 from the description in devices.inc so it reads: \u0027The device must support cleaning (currently NVMe devices only) and must be in ``error`` state.\u0027 This aligns the API reference with the implementation and the admin guide.","commit_id":"e01f8aff6f3ad59bc4ca3a1fea6b67ee864840ac"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"34ab9e60fc23dc8d1055368081614e5beb2ec574","unresolved":false,"context_lines":[{"line_number":138,"context_line":""},{"line_number":139,"context_line":".. rest_method:: POST /v2/devices/{device_uuid}/clean"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Trigger data cleanup on a device. The device must support cleaning"},{"line_number":142,"context_line":"(currently NVMe devices only) and must be in ``error`` or"},{"line_number":143,"context_line":"``pending_cleaning`` state. Returns ``202 Accepted`` and cleanup"},{"line_number":144,"context_line":"proceeds asynchronously."}],"source_content_type":"text/x-c++src","patch_set":8,"id":"503ac4b1_e63b5e1b","line":141,"updated":"2026-08-09 06:17:35.000000000","message":"The API reference states the device must be in \u0027error\u0027 or \u0027pending_cleaning\u0027 state to trigger cleanup, but the actual API controller (devices.py:250) only accepts \u0027error\u0027 state and rejects \u0027pending_cleaning\u0027 with HTTP 409 Conflict (\u0027Device is already being cleaned\u0027).\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: An operator or API consumer reading the docs would expect to be able to trigger cleanup on a device in pending_cleaning state, but would receive a 409 Conflict error. This could cause confusion during troubleshooting when a device appears stuck in pending_cleaning.\n\n**Suggestion**:\nChange the description to say the device must be in \u0027error\u0027 state only, removing \u0027pending_cleaning\u0027 from the list of acceptable states. Alternatively, if accepting pending_cleaning is intended, update the controller accordingly — but rejecting it is the correct behavior since pending_cleaning means cleanup is already queued.","commit_id":"826e5547dc93a2e64b7dee5a3e53e476c0abb597"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"03d1f953c4a8ab7b870d1a07fedaccdb62a9ecf9","unresolved":false,"context_lines":[{"line_number":86,"context_line":"  - updated_at: updated"},{"line_number":87,"context_line":"  - links: links"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"**Example response: show details of a specific device**"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. literalinclude:: ../../doc/api_samples/devices/devices-getone-resp.json"},{"line_number":92,"context_line":"   :language: javascript"}],"source_content_type":"text/x-c++src","patch_set":17,"id":"501d06ff_15c20ce5","line":89,"updated":"2026-08-17 09:08:02.000000000","message":"devices.inc now lists device_state in the list and show responses, but both examples literalinclude the pre-2.4 JSON samples without device_state. A devices-getone-resp-v24.json sample containing device_state already exists in doc/api_samples/devices/ yet is referenced nowhere, and there is no li...\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: API consumers reading the reference see no device_state in the examples and may not realize the field exists at 2.4, and the v24 sample file is dead weight.\n\n**Recommendation**:\nReference doc/api_samples/devices/devices-getone-resp-v24.json for the show example (with a 2.4 note), and add/reuse a list sample that includes device_state.","commit_id":"e8b31c9b040734c1f740701ae9022906052cfde5"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"b38c109987fca7174f1ea4b197d32bb6c87a0979","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"**Example response: show details of a specific device**"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. literalinclude:: ../../doc/api_samples/devices/devices-getone-resp.json"},{"line_number":92,"context_line":"   :language: javascript"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Enable a device"}],"source_content_type":"text/x-c++src","patch_set":19,"id":"ebf38b8b_7bf73e58","line":91,"updated":"2026-08-21 12:52:15.000000000","message":"devices.inc now lists device_state in both the list and show Response parameters, but the literalinclude examples still use devices-list-resp.json and devices-getone-resp.json, neither of which contains device_state. A v2.4-aware sample (doc/api_samples/devices/devices-getone-resp-v24.json, which includes status and device_state) was added earlier in this series but is referenced nowhere in api-ref or doc sources.\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: The published API reference will describe device_state in the parameter table while the displayed example response omits it, making the new 2.4 feature harder for API consumers to discover and leaving dead sample content in the tree.\n\n**Recommendation**:\nInclude the v2.4 sample alongside (or instead of) the base sample with a microversion note, e.g. add a second literalinclude of devices-getone-resp-v24.json labelled \u0027Example (microversion 2.4+)\u0027, and consider a list-response v2.4 sample similarly.","commit_id":"06a86b81d4eae0121ec60823dcfc6953521166f8"}],"doc/source/admin/nvme-driver.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"c305a2d3977b61da322761c98234c88707f995e0","unresolved":false,"context_lines":[{"line_number":23,"context_line":"   enabled_drivers \u003d nvme_driver"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"   [nvme]"},{"line_number":26,"context_line":"   # JSON filter to select which NVMe devices Cyborg manages."},{"line_number":27,"context_line":"   # All fields are optional; an empty object matches all NVMe devices."},{"line_number":28,"context_line":"   device_spec \u003d {\"vendor_id\": \"8086\", \"product_id\": \"0a54\"}"},{"line_number":29,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"b07f2a96_c625926f","line":26,"updated":"2026-08-06 17:42:34.000000000","message":"The nvme-driver.rst admin guide states that all device_spec fields are optional and that an empty object matches all NVMe devices. This directly contradicts the implementation in devspec.py, which requires at least one of vendor_id, product_id, or address. Additionally, the address field (PCI add...\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: An operator following the documentation may set device_spec to an empty JSON object expecting it to match all NVMe devices. The agent will instead raise PciConfigInvalidWhitelist at startup, preventing device discovery. Operators also cannot use PCI address filtering because the field is undocume...\n\n**Priority**: Before merge\n**Why This Matters**: An operator following the documentation may set device_spec to an empty JSON object expecting it to match all NVMe devices. The agent will instead raise PciConfigInvalidWhitelist at startup, preventing device discovery. Operators also cannot use PCI address filtering because the field is undocume...\n\n**Recommendation**:\nUpdate the device_spec section to state that at least one of vendor_id, product_id, or address is required. Document the address field (PCI address glob or /regex/ syntax). Remove or correct the \u0027empty object matches all devices\u0027 claim. Optionally note that device_spec is a MultiStrOpt and can be specified multiple times.","commit_id":"bb70a18e8a6fb11c2ad1c1726929694612fb0f2b"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"96df2cc543ff8319559e86212a9c6e3972cf5bf0","unresolved":false,"context_lines":[{"line_number":74,"context_line":"2. **Block Erase** (``sanitize`` + ``block``): if ``sanicap`` bit 1"},{"line_number":75,"context_line":"   (BES) is set."},{"line_number":76,"context_line":"3. **Write Zeroes** (``zero``): if ``oncs`` bit 3 (WZ) is set."},{"line_number":77,"context_line":"4. **Format NVM** with Secure Erase: if ``oacs`` bit 3 (NS_MGMT) is"},{"line_number":78,"context_line":"   set."},{"line_number":79,"context_line":"5. No cleanup available: the device is placed in ``error`` state and"},{"line_number":80,"context_line":"   an operator alert is logged."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ac036cee_471b9002","line":77,"updated":"2026-08-07 08:09:54.000000000","message":"The NVMe driver admin guide documents a 5-step cleanup action selection hierarchy that includes \u0027Format NVM with Secure Erase\u0027 (step 4) and \u0027No cleanup available: device placed in error state\u0027 (step 5). Neither matches the actual driver code, which has no Format NVM cleanup path and falls back to...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators reading this guide will expect Format NVM Secure Erase to be used for devices that support NS Management but lack sanitize/write-zeroes capabilities, and will expect unsupported devices to be in error state. In reality those devices receive a full shred and unsupported-policy devices ar...\n\n**Suggestion**:\nRemove step 4 (Format NVM) from the selection hierarchy and update step 5 to describe the actual fallback behavior: \u00274. Full Shred (zero_shred): if none of the above capabilities are available, the driver falls back to a full shred. If the configured action/strategy combination cannot be satisfied (e.g. sanitize requested but device lacks sanitize support), the device is excluded from the pool during discovery and an error is logged.\u0027","commit_id":"b2c5109ed500b8b76ace36b0da4594efcc74ce49"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d6708321055c84a5516741e0d986ccfdd12e6ff0","unresolved":false,"context_lines":[{"line_number":87,"context_line":"   discover"},{"line_number":88,"context_line":"      |"},{"line_number":89,"context_line":"      v"},{"line_number":90,"context_line":"   available ──bind──\u003e allocated ──unbind──\u003e pending_cleaning"},{"line_number":91,"context_line":"      ^                                          |"},{"line_number":92,"context_line":"      |                                          v"},{"line_number":93,"context_line":"      +────────── cleanup success ────────── cleaning"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ee7ea3f6_b56e7478","line":90,"updated":"2026-08-07 17:23:23.000000000","message":"The ASCII art device lifecycle diagram in nvme-driver.rst shows manual POST /clean transitioning directly from \u0027error\u0027 to \u0027available\u0027, but the actual implementation routes through \u0027pending_cleaning\u0027 and \u0027cleaning\u0027 states before reaching \u0027available\u0027 or returning to \u0027error\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Operators relying on the diagram may believe POST /clean immediately returns a device to \u0027available\u0027 state, when in fact it must pass through pending_cleaning and cleaning first. This could cause confusion about when a device becomes ready for reallocation.\n\n**Suggestion**:\nUpdate the diagram to show the manual POST /clean path routing through pending_cleaning → cleaning (like the automatic path) rather than jumping directly to available. Alternatively, add a note below the diagram clarifying that manual cleanup follows the same pending_cleaning → cleaning → available/error transition as automatic cleanup.","commit_id":"e01f8aff6f3ad59bc4ca3a1fea6b67ee864840ac"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"0f4a89ca34126949bc8f144862c0ea40656efdcd","unresolved":false,"context_lines":[{"line_number":145,"context_line":"      |                                          v"},{"line_number":146,"context_line":"      +────────── cleanup success ────────── cleaning"},{"line_number":147,"context_line":"      |                                          |"},{"line_number":148,"context_line":"      +\u003c──── manual POST /clean ──── error \u003c─────+"},{"line_number":149,"context_line":"                                   (cleanup fail)"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"``device_state`` values:"}],"source_content_type":"text/x-rst","patch_set":9,"id":"4881cb56_ecd41cfc","line":148,"updated":"2026-08-11 10:36:02.000000000","message":"The device lifecycle ASCII-art diagram in the admin guide draws an arrow from \u0027error\u0027 directly to \u0027available\u0027 labeled \u0027manual POST /clean\u0027. In the actual implementation, POST /clean dispatches cleanup asynchronously (returns 202), and the device transitions through pending_cleaning and cleaning b...\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: An operator reading the diagram may expect the device to be immediately available after calling POST /clean, rather than going through the async pending_cleaning and cleaning states. This could cause confusion when polling device_state after triggering cleanup.\n\n**Recommendation**:\nEither redraw the \u0027manual POST /clean\u0027 arrow to route through pending_cleaning and cleaning (as the initial path does), or add a note clarifying that POST /clean triggers the same async pipeline (pending_cleaning -\u003e cleaning -\u003e available/error) rather than a direct state reset.","commit_id":"56600fe8c0bf7e97fb0f67c1954aa456450d743d"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"791e36e6ff923fd9f79e451bf9e846622bd3f4d6","unresolved":false,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"4. Restart services in order: conductor, API, then agent."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The agent is compatible with N-1 conductor versions. If the conductor"},{"line_number":248,"context_line":"has not been upgraded yet, cleanup dispatch calls are silently skipped"},{"line_number":249,"context_line":"and logged as warnings."},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"f4a2f77c_bb4cb8f8","line":247,"updated":"2026-08-11 17:01:46.000000000","message":"The admin guide states that if the conductor has not been upgraded, \u0027cleanup dispatch calls are silently skipped and logged as warnings.\u0027 The actual code does not silently skip cleanup. The API layer returns HTTP 400 badRequest when the agent RPC version is too old, and the conductor\u0027s dispatch_c...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: An operator reading the upgrade guide may believe cleanup failures during rolling upgrades are benign (silently skipped), when in fact devices will be set to \u0027error\u0027 state requiring manual intervention, or cleanup requests will be rejected at the API layer. This could lead to unexpected device un...\n\n**Suggestion**:\nRewrite the paragraph to accurately describe both failure modes: (1) the API layer rejects cleanup requests with HTTP 400 if the agent does not support RPC 1.1, and (2) if the conductor dispatches cleanup to an older agent, the device transitions to \u0027error\u0027 state. Alternatively, remove the paragraph if the compatibility details are too implementation-specific for an admin guide.","commit_id":"47d84a100aad5437ba01c5a508a9d355a2701f5a"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"4262e95a038abdb883e92c17ed12bb8345f9f8d9","unresolved":false,"context_lines":[{"line_number":188,"context_line":""},{"line_number":189,"context_line":".. code-block:: bash"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"   openstack accelerator device clean \u003cdevice-uuid\u003e"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Or via the REST API:"},{"line_number":194,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"66a43194_ccddbeb4","line":191,"updated":"2026-08-12 10:38:53.000000000","message":"The admin guide presents \u0027openstack accelerator device clean \u003cdevice-uuid\u003e\u0027 as a usable command, but no OSC plugin implementing this subcommand exists in the cyborg repository or as a dependency. Operators following the guide will encounter an error.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Operators following the documented procedure for manual cleanup will run \u0027openstack accelerator device clean\u0027 and get a command-not-found or unrecognized-argument error. They must instead use the REST API (curl) approach documented below it.\n\n**Suggestion**:\nEither (1) qualify the command with a note that the OSC plugin must support it, or (2) remove the CLI example and keep only the curl example, or (3) implement the command in the cyborg OSC plugin.","commit_id":"926fbdc9e7da51d1d0f794490a3cb6cfad57a08e"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"6cdf0d9dc928b70c0e34420917ac3f2fddfa561b","unresolved":false,"context_lines":[{"line_number":253,"context_line":""},{"line_number":254,"context_line":"1. Run the database migration:"},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"   .. code-block:: bash"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"      cyborg-manage db sync"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3bd3b558_12b8749f","line":256,"updated":"2026-08-13 06:51:01.000000000","message":"The admin NVMe guide\u0027s Upgrade section uses `cyborg-manage db sync` and `cyborg-manage db online_data_migrations`, but no `cyborg-manage` binary exists in this project. The actual entry points are `cyborg-dbsync` (subcommand `upgrade`) and `cyborg-dbsync online_data_migrations`, as defined in pyp...\n\n**Severity**: HIGH | **Confidence**: 1.0\n\n**Risk**: Operators following the upgrade guide will encounter \u0027command not found\u0027 errors when running the documented steps, blocking upgrades that involve the NVMe driver.\n\n**Priority**: Before merge\n**Why This Matters**: Operators following the upgrade guide will encounter \u0027command not found\u0027 errors when running the documented steps, blocking upgrades that involve the NVMe driver.\n\n**Recommendation**:\nReplace `cyborg-manage db sync` with `cyborg-dbsync upgrade` and `cyborg-manage db online_data_migrations` with `cyborg-dbsync online_data_migrations`, matching the project\u0027s actual command names.","commit_id":"765b9840fd84af9b2c828d95c35d99cca6d64651"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"9e2055390b939074e8324cc351f04201a242eed5","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  driver queries the device capabilities and picks the most secure"},{"line_number":57,"context_line":"  available method."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"``clear_strategy``"},{"line_number":60,"context_line":"  Override the sanitize sub-action. One of ``auto`` (default),"},{"line_number":61,"context_line":"  ``crypto`` (Crypto Erase), or ``block`` (Block Erase). Only used"},{"line_number":62,"context_line":"  when ``clear_action`` is ``sanitize`` or resolves to ``sanitize``"}],"source_content_type":"text/x-rst","patch_set":14,"id":"44ce48db_b65feb7c","line":59,"updated":"2026-08-13 15:30:30.000000000","message":"The admin guide describes clear_strategy as \u0027Only used when clear_action is sanitize or resolves to sanitize under auto.\u0027 However, the zero+crypto combination is explicitly rejected at startup as invalid, meaning clear_strategy does affect validation when clear_action is zero.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Operators reading the field description alone would not realize that specifying clear_action\u003dzero with clear_strategy\u003dcrypto will cause agent startup failure. The matrix below clarifies this, but the description text is misleading on its own.\n\n**Suggestion**:\nUpdate the clear_strategy description to note the zero+crypto rejection, e.g.: \u0027Only meaningful when clear_action is sanitize or auto; however, clear_action\u003dzero with clear_strategy\u003dcrypto is explicitly rejected at startup.\u0027","commit_id":"f4d12aec1c42ccd92cb8e8f51350a7718bee9416"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"9e2055390b939074e8324cc351f04201a242eed5","unresolved":false,"context_lines":[{"line_number":188,"context_line":""},{"line_number":189,"context_line":".. code-block:: bash"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"   openstack accelerator device clean \u003cdevice-uuid\u003e"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Or via the REST API:"},{"line_number":194,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"c383211a_04049ed3","line":191,"updated":"2026-08-13 15:30:30.000000000","message":"The admin NVMe driver guide presents \u0027openstack accelerator device clean \u003cuuid\u003e\u0027 as a working CLI command. No such command exists: the project has no OSC plugin and python-cyborgclient does not implement a device clean subcommand.\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: Operators following the guide will attempt \u0027openstack accelerator device clean\u0027 and get \u0027command not found\u0027 or \u0027argument device: invalid choice\u0027 errors. The guide does provide correct curl alternatives, but the CLI examples undermine trust in the documentation.\n\n**Priority**: Before merge\n**Why This Matters**: Operators following the guide will attempt \u0027openstack accelerator device clean\u0027 and get \u0027command not found\u0027 or \u0027argument device: invalid choice\u0027 errors. The guide does provide correct curl alternatives, but the CLI examples undermine trust in the documentation.\n\n**Recommendation**:\nRemove the \u0027openstack accelerator device clean\u0027 CLI example and keep only the REST API curl example, or clearly label it as a proposed command not yet implemented. For \u0027openstack accelerator device show -c device_state\u0027, note that device_state is currently only visible via the REST API with the microversion 2.4 header.","commit_id":"f4d12aec1c42ccd92cb8e8f51350a7718bee9416"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"9e2055390b939074e8324cc351f04201a242eed5","unresolved":false,"context_lines":[{"line_number":214,"context_line":"If Nova reports ``No valid host was found`` for an NVMe device profile,"},{"line_number":215,"context_line":"confirm that the backing NVMe devices are not already stuck in ``error``"},{"line_number":216,"context_line":"state:"},{"line_number":217,"context_line":""},{"line_number":218,"context_line":".. code-block:: bash"},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"   mysql -u root cyborg -e \\"}],"source_content_type":"text/x-rst","patch_set":14,"id":"38bddbf2_520f8d9e","line":217,"updated":"2026-08-13 15:30:30.000000000","message":"The upgrade section of the admin NVMe driver guide uses \u0027cyborg-manage db sync\u0027 and \u0027cyborg-manage db online_data_migrations\u0027. The actual installed commands are \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027 as defined by pyproject.toml entry points and existing project docume...\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: Operators running \u0027cyborg-manage db sync\u0027 will get \u0027command not found\u0027. This blocks the documented upgrade workflow and causes confusion since the correct commands are documented elsewhere in the same doc set.\n\n**Priority**: Before merge\n**Why This Matters**: Operators running \u0027cyborg-manage db sync\u0027 will get \u0027command not found\u0027. This blocks the documented upgrade workflow and causes confusion since the correct commands are documented elsewhere in the same doc set.\n\n**Recommendation**:\nReplace \u0027cyborg-manage db sync\u0027 with \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-manage db online_data_migrations\u0027 with \u0027cyborg-dbsync online_data_migrations\u0027. The \u0027cyborg-status upgrade check\u0027 command at line 231 is correct and needs no change.","commit_id":"f4d12aec1c42ccd92cb8e8f51350a7718bee9416"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8738f593aa32ca6cc7f0d657a4b5c60273aafe70","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":130,"context_line":"    | zero         | auto/block     | write zeroes, else shred              |"},{"line_number":131,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":132,"context_line":"    | zero         | crypto         | invalid — device excluded at startup  |"},{"line_number":133,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Device Lifecycle"}],"source_content_type":"text/x-rst","patch_set":15,"id":"1707d5c8_c1fd5641","line":132,"updated":"2026-08-14 16:57:56.000000000","message":"The clear_action x clear_strategy matrix row \u0027zero | crypto | invalid - device excluded at startup\u0027 is wrong: the code rejects this combination with PciConfigInvalidWhitelist while parsing device_spec, aborting discovery for the driver rather than excluding one device.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: An operator who sets clear_action\u003dzero with clear_strategy\u003dcrypto expects one device to be skipped; instead NVMe discovery fails at startup. Troubleshooting based on the doc will look in the wrong place (device capabilities instead of configuration validation).\n\n**Suggestion**:\nChange the row to \u0027invalid - agent startup fails with PciConfigInvalidWhitelist; fix the device_spec\u0027 to match devspec.py behavior, and keep the capability-based exclusion wording only for the unsatisfiable-caps case.","commit_id":"6fdaf7c94cc45d261a6372159740a7e68e181dfe"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8738f593aa32ca6cc7f0d657a4b5c60273aafe70","unresolved":false,"context_lines":[{"line_number":140,"context_line":"   discover"},{"line_number":141,"context_line":"      |"},{"line_number":142,"context_line":"      v"},{"line_number":143,"context_line":"   available ──bind──\u003e allocated ──unbind──\u003e pending_cleaning"},{"line_number":144,"context_line":"      ^                                          |"},{"line_number":145,"context_line":"      |                                          v"},{"line_number":146,"context_line":"      +────────── cleanup success ────────── cleaning"}],"source_content_type":"text/x-rst","patch_set":15,"id":"cb63953d_97708f13","line":143,"updated":"2026-08-14 16:57:56.000000000","message":"The ASCII state machine in the new admin guide attaches \u0027cleanup success\u0027 to the cleaning node and shows error returning to available via POST /clean, which contradicts both the prose below it and the actual state semantics.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators reading the diagram will conclude that \u0027cleaning\u0027 means cleanup succeeded and that POST /clean immediately frees an error device, leading to incorrect operational decisions (e.g. expecting a device to be schedulable right after issuing POST /clean).\n\n**Suggestion**:\nRedraw the diagram so the \u0027cleanup success\u0027 label sits on the cleaning-\u003eavailable edge and \u0027cleanup fail\u0027 on the cleaning-\u003eerror edge, and draw POST /clean as error-\u003epending_cleaning (restarting cleanup), matching the prose and the device_state value descriptions.","commit_id":"6fdaf7c94cc45d261a6372159740a7e68e181dfe"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8738f593aa32ca6cc7f0d657a4b5c60273aafe70","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"   .. code-block:: bash"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"      cyborg-manage db sync"},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"2. Run online data migrations:"},{"line_number":261,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"6bddee6d_06239f8c","line":258,"updated":"2026-08-14 16:57:56.000000000","message":"The new admin guide instructs operators to run \u0027cyborg-manage db sync\u0027 and \u0027cyborg-manage db online_data_migrations\u0027, but this project ships no cyborg-manage binary and no \u0027db\u0027 subcommand structure.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators following the NVMe upgrade steps verbatim will get \u0027command not found: cyborg-manage\u0027 and may not run the schema migration or the device_state backfill, leaving devices with NULL device_state and failing the cyborg-status upgrade check.\n\n**Suggestion**:\nReplace with the real commands used elsewhere in the docs: \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027, or link to :doc:/admin/upgrade instead of duplicating the procedure with wrong command names.","commit_id":"6fdaf7c94cc45d261a6372159740a7e68e181dfe"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"4d3f918d42c0a4f3b07f6a9152c04b38025f64b0","unresolved":false,"context_lines":[{"line_number":140,"context_line":"   discover"},{"line_number":141,"context_line":"      |"},{"line_number":142,"context_line":"      v"},{"line_number":143,"context_line":"   available ──bind──\u003e allocated ──unbind──\u003e pending_cleaning"},{"line_number":144,"context_line":"      ^                                          |"},{"line_number":145,"context_line":"      |                                          v"},{"line_number":146,"context_line":"      +────────── cleanup success ────────── cleaning"}],"source_content_type":"text/x-rst","patch_set":16,"id":"d8e24980_d6151c93","line":143,"updated":"2026-08-15 17:40:35.000000000","message":"The ASCII state machine draws the \u0027cleanup success\u0027 transition into \u0027available\u0027 from a line that visually originates near \u0027pending_cleaning\u0027, and no edge connects the \u0027cleaning\u0027 box to that success arrow, even though cleanup actually executes from the \u0027cleaning\u0027 state.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Operators debugging a stuck device can misread where cleanup success is reported from and where a retry from \u0027error\u0027 re-enters the state machine.\n\n**Suggestion**:\nRedraw the diagram so a distinct edge runs from the \u0027cleaning\u0027 box back to \u0027available\u0027, keeping the cleaning -\u003e error failure edge separate.","commit_id":"a486cd95b1139b745196975c4268130597f8da7a"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"03d1f953c4a8ab7b870d1a07fedaccdb62a9ecf9","unresolved":false,"context_lines":[{"line_number":232,"context_line":"   curl -s \\"},{"line_number":233,"context_line":"     -H \"X-Auth-Token: $TOKEN\" \\"},{"line_number":234,"context_line":"     -H \"OpenStack-API-Version: accelerator 2.4\" \\"},{"line_number":235,"context_line":"     \"$ACCEL_URL/devices/\u003cdevice-uuid\u003e\""},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Devices in ``error`` remain fully reserved in Placement until cleanup is"},{"line_number":238,"context_line":"retried successfully, so a pool of all-``error`` NVMe devices will cause"}],"source_content_type":"text/x-rst","patch_set":17,"id":"d400b011_3ecc928d","line":235,"updated":"2026-08-17 09:08:02.000000000","message":"Every curl example in the new guides is broken. The accelerator catalog endpoint is \u0027http://host/accelerator\u0027 (devstack/settings: CYBORG_API_URL, and api sample links show /accelerator/v2/devices/...), but the docs call \"$ACCEL_URL/devices/$uuid\" without the /v2 segment (404), and other blocks us...\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: Operators following the \u0027No valid host\u0027 troubleshooting and cleanup-retry procedures get 404s or empty-URL curl errors during incident response, defeating the stated purpose of the admin guide.\n\n**Priority**: Before merge\n**Why This Matters**: Operators following the \u0027No valid host\u0027 troubleshooting and cleanup-retry procedures get 404s or empty-URL curl errors during incident response, defeating the stated purpose of the admin guide.\n\n**Recommendation**:\nChange the ACCEL_URL examples to \"$ACCEL_URL/v2/devices/$uuid\" (and /v2/devices/$uuid/clean), and either define CYBORG_URL (e.g. ACCEL_URL\u003d$(openstack endpoint list --service accelerator ...)) before use or reuse the already-defined $ACCEL_URL with the /v2 prefix in all blocks (admin nvme-driver.rst:196-200, contributor nvme-driver.rst:497-499).","commit_id":"e8b31c9b040734c1f740701ae9022906052cfde5"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"84199553a79d36fafe88321339a3f5b2bb71d6ae","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":130,"context_line":"    | zero         | auto/block     | write zeroes, else shred              |"},{"line_number":131,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":132,"context_line":"    | zero         | crypto         | invalid — device excluded at startup  |"},{"line_number":133,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Device Lifecycle"}],"source_content_type":"text/x-rst","patch_set":18,"id":"d8df29a5_1490363f","line":132,"updated":"2026-08-18 07:29:51.000000000","message":"The cleanup policy matrix in the new admin guide states that the zero/crypto combination is \u0027invalid - device excluded at startup\u0027, implying a per-device exclusion like the capability-mismatch path. In the code, devspec.NVMeDeviceSpec._validate_cleanup_policy() raises PciConfigInvalidWhitelist when parsing the spec, and NVMeDriver.discover() calls NVMeDeviceSpec.from_config_list() unguarded, so the exception aborts the whole discover() call (resource_tracker discover_all/update_usage), not a single device. No device matched by that spec is reported, and the failure is a configuration error, not a logged exclusion of one device.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: An operator who configures zero/crypto expecting only the affected device to be skipped will instead break NVMe discovery entirely (InvalidConfiguration traceback in the agent log, no NVMe devices reported), and will look for a per-device \u0027excluded\u0027 log line that never appears.\n\n**Suggestion**:\nChange the matrix cell to something like \u0027invalid configuration: PciConfigInvalidWhitelist raised when the spec is parsed; discovery for the NVMe driver fails until the spec is corrected\u0027, and optionally note that unlike capability mismatch this is rejected for the whole spec, not one device.","commit_id":"4ac62f0cae017da2ae9fea4c42437277049b49d9"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"84199553a79d36fafe88321339a3f5b2bb71d6ae","unresolved":false,"context_lines":[{"line_number":197,"context_line":"   curl -X POST \\"},{"line_number":198,"context_line":"     -H \"X-Auth-Token: $TOKEN\" \\"},{"line_number":199,"context_line":"     -H \"OpenStack-API-Version: accelerator 2.4\" \\"},{"line_number":200,"context_line":"     $CYBORG_URL/v2/devices/\u003cdevice-uuid\u003e/clean"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"The endpoint returns ``202 Accepted`` and cleanup proceeds"},{"line_number":203,"context_line":"asynchronously."}],"source_content_type":"text/x-rst","patch_set":18,"id":"bec206da_2dcd1274","line":200,"updated":"2026-08-18 07:29:51.000000000","message":"The primary manual-cleanup examples in both the new admin guide and the contributor guide send the POST /clean request to \u0027$CYBORG_URL/v2/devices/\u003cuuid\u003e/clean\u0027, but CYBORG_URL is not set by DevStack\u0027s openrc or defined anywhere in the repository. Sourcing openrc admin admin as instructed defines OS_* variables only, so the curl command posts to a relative URL and fails. The contributor guide\u0027s own troubleshooting section demonstrates the correct pattern (resolve ACCEL_URL via \u0027openstack endpoint list --service accelerator\u0027), which the two workflow examples do not follow.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Operators and contributors following the documented retry-cleanup procedure (the key operational remedy for error-state devices) get a failing curl command and must reverse-engineer the endpoint URL themselves, undermining the guide\u0027s purpose.\n\n**Suggestion**:\nDefine the endpoint before the curl, e.g. \u0027CYBORG_URL\u003d$(openstack endpoint list --service accelerator --interface public -f value -c URL)\u0027 or reuse the ACCEL_URL pattern already used in the contributor troubleshooting section, in both doc/source/admin/nvme-driver.rst and doc/source/contributor/nvme-driver.rst.","commit_id":"4ac62f0cae017da2ae9fea4c42437277049b49d9"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"84199553a79d36fafe88321339a3f5b2bb71d6ae","unresolved":false,"context_lines":[{"line_number":271,"context_line":""},{"line_number":272,"context_line":"4. Restart services in order: conductor, API, then agent."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":"The agent is compatible with N-1 conductor versions. If the conductor"},{"line_number":275,"context_line":"has not been upgraded yet, cleanup dispatch calls are silently skipped"},{"line_number":276,"context_line":"and logged as warnings."},{"line_number":277,"context_line":""}],"source_content_type":"text/x-rst","patch_set":18,"id":"620fbc1f_8405cd4b","line":274,"updated":"2026-08-18 07:29:51.000000000","message":"The admin guide upgrade section states \u0027The agent is compatible with N-1 conductor versions. If the conductor has not been upgraded yet, cleanup dispatch calls are silently skipped and logged as warnings.\u0027 In the code, the only N-1 handling is the conductor (and the API\u0027s clean endpoint) checking AgentAPI.can_send_version(\u00271.1\u0027) - i.e. an old AGENT, not an old conductor. When that check fails, the conductor sets the device to error state (visible in the DB/API), and the API path returns 400; neither path silently skips anything. A pre-cleanup (1.0) conductor receiving dispatch_cleanup from the new API has no version guard at all and would fail the RPC rather than skip it.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: An operator doing a rolling upgrade following this section will mispredict outcomes: with an old agent, devices transition to error (and in the API path the clean request is rejected with 400), which they would need to remediate; there is no silent-skip mode and no warning-only path tied to conductor version at all.\n\n**Suggestion**:\nRewrite the paragraph to match the code: state that the conductor and API verify the agent supports RPC 1.1 before dispatching cleanup, that an old agent causes the device to be marked error (API returns 400), and that the conductor must be upgraded before the API/agent for cleanup dispatch to work; or delete the unsupported claim.","commit_id":"4ac62f0cae017da2ae9fea4c42437277049b49d9"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"b38c109987fca7174f1ea4b197d32bb6c87a0979","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":130,"context_line":"    | zero         | auto/block     | write zeroes, else shred              |"},{"line_number":131,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":132,"context_line":"    | zero         | crypto         | invalid — device excluded at startup  |"},{"line_number":133,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Device Lifecycle"}],"source_content_type":"text/x-rst","patch_set":19,"id":"f1099d88_8e6a0fdd","line":132,"updated":"2026-08-21 12:52:15.000000000","message":"The cleanup policy matrix cell for clear_action\u003dzero with clear_strategy\u003dcrypto says \u0027invalid - device excluded at startup\u0027. The code path actually raises PciConfigInvalidWhitelist while parsing the device_spec during driver discovery, which is a configuration error at agent startup, not per-device exclusion. The same document elsewhere correctly says an empty device_spec \u0027raises PciConfigInvalidWhitelist at agent startup\u0027, so the matrix cell contradicts the described mechanism.\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: An operator who misconfigures zero+crypto expects the agent to start with one device missing; instead agent startup/discovery fails with an exception, and the troubleshooting path described (fix config or replace device) does not match the observed failure.\n\n**Recommendation**:\nChange the cell text to something like \u0027invalid - agent startup fails with PciConfigInvalidWhitelist\u0027, consistent with the empty-device_spec description earlier in the same document.","commit_id":"06a86b81d4eae0121ec60823dcfc6953521166f8"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"b38c109987fca7174f1ea4b197d32bb6c87a0979","unresolved":false,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"4. Restart services in order: conductor, API, then agent."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The agent is compatible with N-1 conductor versions. If the conductor"},{"line_number":248,"context_line":"has not been upgraded yet, cleanup dispatch calls are silently skipped"},{"line_number":249,"context_line":"and logged as warnings."},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":19,"id":"a4b21e51_ddfd6394","line":247,"updated":"2026-08-21 12:52:15.000000000","message":"The new admin guide\u0027s Upgrade section states: \u0027The agent is compatible with N-1 conductor versions. If the conductor has not been upgraded yet, cleanup dispatch calls are silently skipped and logged as warnings.\u0027 The actual code implements something different: the version gate is on the agent RPC (not the conductor), cleanup is not \u0027silently skipped\u0027, and the device is actively marked error.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: An operator following this guide during a rolling upgrade would expect cleanup to be skipped with warnings and retried later. In reality devices transition to \u0027error\u0027 state (blocking reallocation until manual intervention) or POST /clean returns 400. This causes misdiagnosis during upgrades, the exact scenario the section exists to support.\n\n**Suggestion**:\nRewrite the paragraph to describe the actual behavior: when the agent RPC is pinned below 1.1, conductor dispatch_cleanup logs a warning and marks the device \u0027error\u0027, and the API returns 400 until agents are upgraded and the cap is raised. Alternatively remove the unsupported N-1 claim if no such compatibility guarantee is intended.","commit_id":"06a86b81d4eae0121ec60823dcfc6953521166f8"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d76461fa8477688d28aa8e0a48511373bc400223","unresolved":false,"context_lines":[{"line_number":44,"context_line":""},{"line_number":45,"context_line":"``product_id``"},{"line_number":46,"context_line":"  PCI product ID (hex string, e.g. ``\"0a54\"``)."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"``address``"},{"line_number":49,"context_line":"  PCI address filter. Accepts an exact address (``\"0000:01:00.0\"``),"},{"line_number":50,"context_line":"  a glob (``\"*:01:*.*\"``), or a ``/regex/`` pattern"}],"source_content_type":"text/x-rst","patch_set":27,"id":"0b409475_b9ad58dd","line":47,"updated":"2026-09-01 09:52:34.000000000","message":"The admin guide says the `address` field accepts \"a `/regex/` pattern (`\\\"/0000:0[12]:.*.*/\\\"`)\". NVMeDeviceSpec.from_config wraps strings in WhitelistPciAddress, which routes strings to PciAddressGlobSpec; the example string fails glob parsing and raises PciConfigInvalidWhitelist, aborting agent startup. The only supported regex form is a JSON dict of per-field regexes (e.g. {\"bus\": \"0[12]\", \"slot\": \".*\"}), as documented in the [nvme] device_spec option help.\n\n**Severity**: WARNING | **Confidence**: 0.92\n\n**Impact**: An operator who selects devices with the documented regex example gets an agent that fails to start with a PciConfigInvalidWhitelist error instead of matching devices, and may wrongly conclude their filter or hardware is unusable.\n\n**Suggestion**:\nReplace the `/regex/` example with the supported dict form, e.g. address \u003d {\"domain\": \".*\", \"bus\": \"0[12]\", \"slot\": \".*\", \"function\": \".*\"}, or drop the regex sentence and cross-reference the [nvme] device_spec option help.","commit_id":"dd0f8392948266425deb5e61a573dc6a82c1cb6f"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d76461fa8477688d28aa8e0a48511373bc400223","unresolved":false,"context_lines":[{"line_number":228,"context_line":""},{"line_number":229,"context_line":"   .. code-block:: bash"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"      cyborg-manage db sync"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"2. Run online data migrations:"},{"line_number":234,"context_line":""}],"source_content_type":"text/x-rst","patch_set":27,"id":"d9364c8c_f2aa6afb","line":231,"updated":"2026-09-01 09:52:34.000000000","message":"The new admin guide\u0027s Upgrade section tells operators to run `cyborg-manage db sync` and `cyborg-manage db online_data_migrations`. Cyborg has no `cyborg-manage` console script; the packaged commands are `cyborg-dbsync upgrade` and `cyborg-dbsync online_data_migrations` (pyproject.toml entry points, doc/source/cli/cyborg-dbsync.rst, devstack scripts). The `db sync` subcommand form is also wrong: cyborg-dbsync uses `upgrade`.\n\n**Severity**: WARNING | **Confidence**: 0.95\n\n**Impact**: An operator following the upgrade runbook verbatim during a release upgrade hits \u0027command not found\u0027 at the exact moment schema migrations and device_state online data migrations must run, potentially leaving NULL device_state rows and failing `cyborg-status upgrade check`.\n\n**Suggestion**:\nReplace the two commands with `cyborg-dbsync upgrade` and `cyborg-dbsync online_data_migrations`, matching doc/source/admin/upgrade.rst and doc/source/cli/cyborg-dbsync.rst.","commit_id":"dd0f8392948266425deb5e61a573dc6a82c1cb6f"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3e9d3351fa60c614843a730469c590356b4b9565","unresolved":false,"context_lines":[{"line_number":45,"context_line":"``product_id``"},{"line_number":46,"context_line":"  PCI product ID (hex string, e.g. ``\"0a54\"``)."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"``address``"},{"line_number":49,"context_line":"  PCI address filter. Accepts an exact address (``\"0000:01:00.0\"``),"},{"line_number":50,"context_line":"  a glob (``\"*:01:*.*\"``), or a ``/regex/`` pattern"},{"line_number":51,"context_line":"  (``\"/0000:0[12]:.*.*/\"``)."}],"source_content_type":"text/x-rst","patch_set":28,"id":"7ce957d6_a78de1c7","line":48,"updated":"2026-09-03 18:20:37.000000000","message":"The device_spec field reference says the address filter accepts \u0027a /regex/ pattern\u0027 with example \"/0000:0[12]:.*.*/\". The driver only supports an exact/glob string or a per-field regex dict: NVMeDeviceSpec.from_config passes address strings to pci_devspec.WhitelistPciAddress, which routes strings to PciAddressGlobSpec (hex or \u0027*\u0027 fields only). The documented example fails hex parsing and raises PciConfigInvalidWhitelist/PciDeviceWrongAddressFormat, aborting agent discovery at startup. The config option\u0027s own help text documents \u0027glob ... or per-field regex dict\u0027 with no /regex/ string form.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: An operator who copies the documented regex example gets an agent startup failure (PciConfigInvalidWhitelist) instead of regex matching, and the documented escape hatch for address filtering simply does not exist.\n\n**Suggestion**:\nReplace the \u0027/regex/\u0027 string form with the supported per-field regex dict, e.g. address \u003d {\"domain\": \"0000\", \"bus\": \"0[12]\", \"slot\": \".*\", \"function\": \".*\"}, and note that plain strings are treated as exact/glob addresses (matching the [nvme] device_spec option help).","commit_id":"b2b5e954f10ccb3dd6d979a036087c2b08ac06ef"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3e9d3351fa60c614843a730469c590356b4b9565","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":130,"context_line":"    | zero         | auto/block     | write zeroes, else shred              |"},{"line_number":131,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":132,"context_line":"    | zero         | crypto         | invalid — device excluded at startup  |"},{"line_number":133,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Device Lifecycle"}],"source_content_type":"text/x-rst","patch_set":28,"id":"68adabe0_541bc753","line":132,"updated":"2026-09-03 18:20:37.000000000","message":"The clear_action x clear_strategy matrix marks the \u0027zero + crypto\u0027 cell as \u0027invalid - device excluded at startup\u0027. Validation of that combination happens in NVMeDeviceSpec._validate_cleanup_policy, which raises PciConfigInvalidWhitelist when the spec list is parsed inside NVMeDriver.discover(). The exception propagates through ResourceTracker.discover_all (no error handling) to AgentManager.init_host, so the agent startup fails for all drivers/devices, not a single excluded device. This differs from the capability-mismatch path, which logs an error and skips just that device.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: An operator misreading the cell will expect the other NVMe devices (and the agent) to keep working with only the matching device skipped; in reality the agent fails to start until the invalid device_spec entry is fixed, causing a broader outage window during configuration changes.\n\n**Suggestion**:\nChange the cell to something like \u0027invalid configuration - PciConfigInvalidWhitelist, agent startup fails (see empty-spec note above)\u0027, and optionally state that capability mismatches for valid specs are the case where a single device is skipped with an error log.","commit_id":"b2b5e954f10ccb3dd6d979a036087c2b08ac06ef"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3e9d3351fa60c614843a730469c590356b4b9565","unresolved":false,"context_lines":[{"line_number":226,"context_line":""},{"line_number":227,"context_line":"1. Run the database migration:"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"   .. code-block:: bash"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"      cyborg-manage db sync"},{"line_number":232,"context_line":""}],"source_content_type":"text/x-rst","patch_set":28,"id":"0c065bc0_51e2f823","line":229,"updated":"2026-09-03 18:20:37.000000000","message":"The new admin guide\u0027s Upgrade section tells operators to run \u0027cyborg-manage db sync\u0027 and \u0027cyborg-manage db online_data_migrations\u0027. Cyborg has no \u0027cyborg-manage\u0027 console script; the installed entry points are cyborg-api, cyborg-conductor, cyborg-dbsync, cyborg-agent, and cyborg-status, and the project\u0027s existing upgrade documentation uses \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027. The correct subcommand is also \u0027upgrade\u0027, not \u0027db sync\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.95\n\n**Impact**: Operators following the new guide during an upgrade will hit \u0027cyborg-manage: command not found\u0027 at the exact steps meant to apply schema migrations and online data migrations, and may skip the required device_state backfill that cyborg-status upgrade check then fails on.\n\n**Suggestion**:\nReplace the two commands with \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027, matching doc/source/admin/upgrade.rst (keep \u0027cyborg-status upgrade check\u0027 as-is; that script exists).","commit_id":"b2b5e954f10ccb3dd6d979a036087c2b08ac06ef"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3e9d3351fa60c614843a730469c590356b4b9565","unresolved":false,"context_lines":[{"line_number":243,"context_line":"      cyborg-status upgrade check"},{"line_number":244,"context_line":""},{"line_number":245,"context_line":"4. Restart services in order: conductor, API, then agent."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The agent is compatible with N-1 conductor versions. If the conductor"},{"line_number":248,"context_line":"has not been upgraded yet, cleanup dispatch calls are silently skipped"},{"line_number":249,"context_line":"and logged as warnings."}],"source_content_type":"text/x-rst","patch_set":28,"id":"7238afe6_dc517229","line":246,"updated":"2026-09-03 18:20:37.000000000","message":"The Upgrade section states \u0027The agent is compatible with N-1 conductor versions. If the conductor has not been upgraded yet, cleanup dispatch calls are silently skipped and logged as warnings.\u0027 No code implements this behavior. ConductorAPI.dispatch_cleanup prepares a cast pinned to version \u00271.1\u0027 with no can_send_version guard, so against an N-1 (1.0) conductor the API call raises a version-cap MessagingError rather than being skipped with a warning. The actual warning path is on the conductor side when the agent RPC pin is below 1.1, and it marks the device error (not skipped): \u0027marking device %s ... as error until agents are upgraded\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Operators planning a rolling upgrade will expect cleanup requests to degrade gracefully with an N-1 conductor; instead POST /clean fails, and when the agent pin is old the device is marked error and requires manual re-clean, which changes their upgrade runbook and expected device availability.\n\n**Suggestion**:\nRewrite the note to match the code: state that POST /v2/devices/{uuid}/clean requires conductor RPC 1.1 (upgrade conductor before or with the API), that a version-pinned agent causes the conductor to log a warning and mark the device error until the pin is raised, and that a too-old agent receiving the call gets HTTP 400 from the API layer.","commit_id":"b2b5e954f10ccb3dd6d979a036087c2b08ac06ef"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"29b53d4500a175aea92217e1ae5c78bd4cd9488a","unresolved":false,"context_lines":[{"line_number":46,"context_line":"  PCI product ID (hex string, e.g. ``\"0a54\"``)."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"``address``"},{"line_number":49,"context_line":"  PCI address filter. Accepts an exact address (``\"0000:01:00.0\"``),"},{"line_number":50,"context_line":"  a glob (``\"*:01:*.*\"``), or a ``/regex/`` pattern"},{"line_number":51,"context_line":"  (``\"/0000:0[12]:.*.*/\"``)."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":30,"id":"dd74e760_d614db6c","line":49,"updated":"2026-09-04 07:59:02.000000000","message":"The new admin guide states that the device_spec ``address`` field accepts an exact address, a glob, or a ``/regex/`` pattern such as ``\"/0000:0[12]:.*.*/\"``. The implementation parses address through pci_devspec.WhitelistPciAddress: a JSON string is always treated as a glob (PciAddressGlobSpec) and per-field regex requires a dict (PciAddressRegexSpec). The slash-wrapped regex string form is never parsed as regex; it fails glob field validation and the agent refuses to start. The supported dict form is not documented in the admin guide.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: An operator who configures device_spec with the documented \"/0000:0[12]:.*.*/\" value gets an agent startup failure (PciDeviceWrongAddressFormat/PciConfigInvalidWhitelist) instead of a regex match, blocking device discovery until the value is rewritten; the actually supported dict regex form is undocumented in the operator guide.\n\n**Suggestion**:\nReplace the \u0027/regex/\u0027 example with the supported per-field dict form, e.g. {\"address\": {\"domain\": \"0000\", \"bus\": \"0[12]\", \"slot\": \"*\", \"function\": \".*\"}}, and note that string addresses are glob-style while dict addresses are per-field regex, matching the [nvme] device_spec help text in cyborg/conf/nvme.py.","commit_id":"dcf37afd5a87f6b4562a1219031bb9a8196f09e4"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"29b53d4500a175aea92217e1ae5c78bd4cd9488a","unresolved":false,"context_lines":[{"line_number":228,"context_line":""},{"line_number":229,"context_line":"   .. code-block:: bash"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"      cyborg-manage db sync"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"2. Run online data migrations:"},{"line_number":234,"context_line":""}],"source_content_type":"text/x-rst","patch_set":30,"id":"3ff9a940_5d1d850c","line":231,"updated":"2026-09-04 07:59:02.000000000","message":"The new admin guide\u0027s Upgrade section tells operators to run \u0027cyborg-manage db sync\u0027 and \u0027cyborg-manage db online_data_migrations\u0027. No \u0027cyborg-manage\u0027 console script exists in this project; the installed tools are cyborg-dbsync and cyborg-status, and the documented upgrade flow in doc/source/admin/upgrade.rst uses \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.95\n\n**Impact**: An operator following the guide during upgrade runs a command that does not exist and fails at step 1, blocking or delaying the documented upgrade path for the device_state migration.\n\n**Suggestion**:\nReplace with \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027 to match doc/source/admin/upgrade.rst, and consider linking to that guide instead of duplicating the steps.","commit_id":"dcf37afd5a87f6b4562a1219031bb9a8196f09e4"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"29b53d4500a175aea92217e1ae5c78bd4cd9488a","unresolved":false,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"4. Restart services in order: conductor, API, then agent."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The agent is compatible with N-1 conductor versions. If the conductor"},{"line_number":248,"context_line":"has not been upgraded yet, cleanup dispatch calls are silently skipped"},{"line_number":249,"context_line":"and logged as warnings."},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":30,"id":"c301340d_61f0eeb2","line":247,"updated":"2026-09-04 07:59:02.000000000","message":"The admin guide states \u0027The agent is compatible with N-1 conductor versions. If the conductor has not been upgraded yet, cleanup dispatch calls are silently skipped and logged as warnings.\u0027 The code shows the opposite direction and a different outcome: ConductorManager.dispatch_cleanup handles an *agent* RPC cap below 1.1 by logging a warning and setting the device to error state (not silently skipping); the API layer additionally rejects the clean request with 400 when agents are pinned. Cleanup dispatch is never \u0027silently skipped\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Operators planning a rolling upgrade are told cleanup calls are skipped with warnings, when in reality devices are moved to error state (and the clean API returns 400) until agent upgrade levels are raised. This misleads upgrade planning and error triage for the new cleanup feature.\n\n**Suggestion**:\nRewrite the note to describe the implemented behavior: when [upgrade_levels] agent pins the agent RPC below 1.1, the conductor logs a warning, marks NVMe devices error (and the clean API returns 400), and behavior recovers once agents are upgraded and the cap is raised.","commit_id":"dcf37afd5a87f6b4562a1219031bb9a8196f09e4"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3b0eed7f7c99d7741456eb4310e8a96bf4833553","unresolved":false,"context_lines":[{"line_number":46,"context_line":"  PCI product ID (hex string, e.g. ``\"0a54\"``)."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"``address``"},{"line_number":49,"context_line":"  PCI address filter. Accepts an exact address (``\"0000:01:00.0\"``),"},{"line_number":50,"context_line":"  a glob (``\"*:01:*.*\"``), or a ``/regex/`` pattern"},{"line_number":51,"context_line":"  (``\"/0000:0[12]:.*.*/\"``)."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":31,"id":"573af985_dc93dd75","line":49,"updated":"2026-09-05 05:27:53.000000000","message":"The admin guide says the \u0027address\u0027 field accepts \u0027a /regex/ pattern (\"/0000:0[12]:.*.*/\")\u0027. The implementation only supports a glob string (PciAddressGlobSpec) or a per-field regex dict like {\"domain\": \".*\", \"slot\": \"[0-2]\"} (PciAddressRegexSpec); there is no \u0027/regex/\u0027 string syntax. A string containing regex metacharacters fails hex parsing in PciAddressGlobSpec and raises PciConfigInvalidWhitelist (via devspec from_config), failing NVMe discovery at agent startup.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators copying the documented \u0027/regex/\u0027 example get PciConfigInvalidWhitelist at agent startup and no NVMe devices are discovered; the correct dict form is never shown in the admin guide.\n\n**Suggestion**:\nReplace the \u0027/regex/\u0027 example with the supported per-field regex dict form, e.g. address \u003d {\"bus\": \"0[12]\", \"slot\": \".*\"}, matching the option help text in cyborg/conf/nvme.py.","commit_id":"d2ca0bcbf2f3cfd4bd209789bca5f95bee22d850"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3b0eed7f7c99d7741456eb4310e8a96bf4833553","unresolved":false,"context_lines":[{"line_number":228,"context_line":""},{"line_number":229,"context_line":"   .. code-block:: bash"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"      cyborg-manage db sync"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"2. Run online data migrations:"},{"line_number":234,"context_line":""}],"source_content_type":"text/x-rst","patch_set":31,"id":"37015e4f_f514b471","line":231,"updated":"2026-09-05 05:27:53.000000000","message":"The new admin guide\u0027s Upgrade section tells operators to run \u0027cyborg-manage db sync\u0027 and \u0027cyborg-manage db online_data_migrations\u0027. Cyborg has no cyborg-manage executable and no \u0027db\u0027 subcommand. The installed console script is \u0027cyborg-dbsync\u0027 (pyproject.toml [project.scripts]) with subcommands \u0027upgrade\u0027 and \u0027online_data_migrations\u0027 (cyborg/cmd/dbsync.py). The project\u0027s own admin/upgrade.rst documents \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.97\n\n**Impact**: An operator following the upgrade runbook during a NVMe-enablement upgrade hits \u0027command not found\u0027 for both migration steps. The device_state backfill (online_data_migrations) is required before mixed-version device APIs behave correctly, so following the doc as written leaves devices without backfilled device_state and blocks the documented upgrade path.\n\n**Suggestion**:\nReplace the two commands with \u0027cyborg-dbsync upgrade\u0027 and \u0027cyborg-dbsync online_data_migrations\u0027, matching doc/source/admin/upgrade.rst.","commit_id":"d2ca0bcbf2f3cfd4bd209789bca5f95bee22d850"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3b0eed7f7c99d7741456eb4310e8a96bf4833553","unresolved":false,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"4. Restart services in order: conductor, API, then agent."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The agent is compatible with N-1 conductor versions. If the conductor"},{"line_number":248,"context_line":"has not been upgraded yet, cleanup dispatch calls are silently skipped"},{"line_number":249,"context_line":"and logged as warnings."},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":31,"id":"7ab485c7_2442211f","line":247,"updated":"2026-09-05 05:27:53.000000000","message":"The guide states \u0027The agent is compatible with N-1 conductor versions. If the conductor has not been upgraded yet, cleanup dispatch calls are silently skipped and logged as warnings.\u0027 No code path does this. Conductor manager dispatch_cleanup(), when the agent does not support RPC 1.1, logs a warning and marks the device ERROR (not skipped). If the conductor itself is N-1 (lacks 1.1), the API\u0027s versioned cast of dispatch_cleanup fails rather than being silently skipped, and doc/source/admin/upgrade.rst explicitly says mixed API/conductor releases are not a supported operating mode.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Operators planning a rolling upgrade may sequence upgrades assuming cleanup requests degrade gracefully (skipped with a warning). In reality devices land in error state requiring manual POST /clean retries, and an N-1 conductor rejects the cleanup cast outright; troubleshooting during upgrade windows will not match the documented behavior.\n\n**Suggestion**:\nRewrite the paragraph to match the code: upgrade conductor and API together (as admin/upgrade.rst requires) before agents; when agents are pinned below 1.1 the driver refuses to start (init_host) or dispatch marks the device error with a logged warning, requiring re-trigger after the cap is raised.","commit_id":"d2ca0bcbf2f3cfd4bd209789bca5f95bee22d850"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"37d98c20175b3e6010aa03dbbcff5d8b25c5786f","unresolved":false,"context_lines":[{"line_number":47,"context_line":""},{"line_number":48,"context_line":"``address``"},{"line_number":49,"context_line":"  PCI address filter. Accepts an exact address (``\"0000:01:00.0\"``),"},{"line_number":50,"context_line":"  a glob (``\"*:01:*.*\"``), or a ``/regex/`` pattern"},{"line_number":51,"context_line":"  (``\"/0000:0[12]:.*.*/\"``)."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"``clear_action``"}],"source_content_type":"text/x-rst","patch_set":32,"id":"5f74d8a0_e17ca90d","line":50,"updated":"2026-09-07 16:19:44.000000000","message":"The new admin guide states the device_spec \u0027address\u0027 field accepts an exact address, a glob, or a \u0027/regex/\u0027 pattern such as \"/0000:0[12]:.*.*/\". In the implementation, NVMeDeviceSpec.from_config() passes string addresses to pci devspec WhitelistPciAddress(address, False), which routes strings to PciAddressGlobSpec. That class only accepts hex fields or \u0027*\u0027, so a \u0027/regex/\u0027 string raises PciConfigInvalidWhitelist. Regex matching is only available via the per-field dict form (e.g. {\"domain\": \".*\", \"bus\": \"02\"}), which the doc omits.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators following the documented \u0027/regex/\u0027 example hit PciConfigInvalidWhitelist at agent startup and the device is never managed; the doc also omits the supported per-field regex dict form, so there is no correct regex guidance.\n\n**Suggestion**:\nReplace the \u0027/regex/\u0027 string example with the supported per-field dict form (e.g. device_spec \u003d {\"address\": {\"bus\": \"0[12]\", \"slot\": \".*\"}}) to match PciAddressRegexSpec and the [nvme] device_spec option help in cyborg/conf/nvme.py, and state that string addresses only support exact values and \u0027*\u0027 globs.","commit_id":"a3aa14527a9c4dab7d9c5f7271aee82cc398aaa3"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"37d98c20175b3e6010aa03dbbcff5d8b25c5786f","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":130,"context_line":"    | zero         | auto/block     | write zeroes, else shred              |"},{"line_number":131,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":132,"context_line":"    | zero         | crypto         | invalid — device excluded at startup  |"},{"line_number":133,"context_line":"    +--------------+----------------+---------------------------------------+"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Device Lifecycle"}],"source_content_type":"text/x-rst","patch_set":32,"id":"070cc5c1_1de3f1a9","line":132,"updated":"2026-09-07 16:19:44.000000000","message":"The cleanup policy matrix row \u0027zero | crypto | invalid - device excluded at startup\u0027 implies the agent starts and skips just that device. The implementation rejects clear_action\u003dzero with clear_strategy\u003dcrypto in NVMeDeviceSpec.__post_init__ via PciConfigInvalidWhitelist, which is raised while parsing device_spec during discover()/init_host(), so the whole agent fails to start rather than excluding one device.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: An operator misconfiguring one device_spec entry as zero+crypto expects the other entries and the rest of the agent to keep working (\u0027device excluded\u0027); instead cyborg-agent fails to start, taking discovery and cleanup for all managed devices down until the config is fixed.\n\n**Suggestion**:\nChange the matrix cell to \u0027invalid - agent startup fails with PciConfigInvalidWhitelist\u0027 so operators know to check agent logs for a config error rather than expecting per-device exclusion.","commit_id":"a3aa14527a9c4dab7d9c5f7271aee82cc398aaa3"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"37d98c20175b3e6010aa03dbbcff5d8b25c5786f","unresolved":false,"context_lines":[{"line_number":140,"context_line":"   discover"},{"line_number":141,"context_line":"      |"},{"line_number":142,"context_line":"      v"},{"line_number":143,"context_line":"   available ──bind──\u003e allocated ──unbind──\u003e pending_cleaning"},{"line_number":144,"context_line":"      ^                                          |"},{"line_number":145,"context_line":"      |                                          v"},{"line_number":146,"context_line":"      +────────── cleanup success ────────── cleaning"}],"source_content_type":"text/x-rst","patch_set":32,"id":"a7936775_038886a1","line":143,"updated":"2026-09-07 16:19:44.000000000","message":"The new lifecycle section shows pending_cleaning -\u003e cleaning -\u003e available and describes \u0027cleaning\u0027 as \u0027Cleanup is in progress\u0027; the contributor guide repeats \u0027pending_cleaning → cleaning → available\u0027. No code path ever assigns DEVICE_STATE_CLEANING: conductor dispatch_cleanup() sets PENDING_CLEANING (conductor/manager.py:110), the agent runs the driver and reports back, and conductor cleanup_complete() sets AVAILABLE or ERROR. \u0027cleaning\u0027 appears only in the enum, the API conflict guard, and the DB migration.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: An operator following the troubleshooting/observation guidance will never see \u0027cleaning\u0027; a device stuck in pending_cleaning (e.g. wedged agent) looks like an undocumented terminal state, and the documented manual-clean arrow into \u0027available\u0027 misrepresents the actual error -\u003e pending_cleaning -\u003e available flow.\n\n**Suggestion**:\nUpdate the state diagram and the state list to match the implemented flow (pending_cleaning -\u003e available/error, with cleanup executing asynchronously while the state remains pending_cleaning), or state explicitly that \u0027cleaning\u0027 is reserved/unused in this release. Fix the same sequence in doc/source/contributor/nvme-driver.rst:505.","commit_id":"a3aa14527a9c4dab7d9c5f7271aee82cc398aaa3"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"37d98c20175b3e6010aa03dbbcff5d8b25c5786f","unresolved":false,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"4. Restart services in order: conductor, API, then agent."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The agent is compatible with N-1 conductor versions. If the conductor"},{"line_number":248,"context_line":"has not been upgraded yet, cleanup dispatch calls are silently skipped"},{"line_number":249,"context_line":"and logged as warnings."},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":32,"id":"1873b08a_f5c8c1db","line":247,"updated":"2026-09-07 16:19:44.000000000","message":"The Upgrade section states \u0027The agent is compatible with N-1 conductor versions. If the conductor has not been upgraded yet, cleanup dispatch calls are silently skipped and logged as warnings.\u0027 The actual guard checks [upgrade_levels] agent (the conductor-to-agent direction), and when the cap is below 1.1 the conductor logs a warning and marks the device ERROR to fence it - the opposite of \u0027silently skipped\u0027. The API layer likewise returns 400 when the agent cap is pinned below 1.1.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Operators planning a rolling upgrade from this doc will expect cleanup requests to be dropped quietly and devices to remain in their prior state; in reality devices are deliberately fenced to error (and POST /clean returns 400) until agents are upgraded and the agent upgrade level is raised - a materially different remediation.\n\n**Suggestion**:\nRewrite the note to match the code: when [upgrade_levels] agent is pinned below 1.1, dispatch_cleanup marks the device error and logs a warning, and POST /v2/devices/{uuid}/clean returns 400; devices return to the pool after agents are upgraded and the cap is raised. Drop or separately justify the unverifiable \u0027N-1 conductor\u0027 claim.","commit_id":"a3aa14527a9c4dab7d9c5f7271aee82cc398aaa3"}],"doc/source/contributor/nvme-driver.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"2d543561c1b1e70fc33e92c372e5192befa3edc0","unresolved":false,"context_lines":[{"line_number":5,"context_line":"Overview"},{"line_number":6,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"This guide provides instructions for configuring NVMe (Non-Volatile Memory"},{"line_number":9,"context_line":"Express) and virtio-rng (Random Number Generator) device emulation and setting"},{"line_number":10,"context_line":"up the NVMe driver in Cyborg for development and testing."},{"line_number":11,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"436ee343_8be414c1","line":8,"updated":"2026-08-12 16:15:47.000000000","message":"The contributor NVMe guide retains sections for adding and verifying virtio-rng devices, and the overview/scope still mention virtio-rng, but the DevStack configuration section was rewritten from the generic PCI driver (which could whitelist RNG devices) to the NVMe-specific driver, which has no...\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: Developers following the guide will add an RNG device to their VM but find no way to configure Cyborg to manage it, creating confusion about whether the NVMe driver supports non-NVMe devices.\n\n**Recommendation**:\nEither remove the virtio-rng sections (Add RNG Device, Verify RNG Device) and update the overview/scope to drop virtio-rng mentions, or add a note explaining that the RNG device setup is for general PCI testing only and is not managed by the nvme_driver.","commit_id":"5c701c65d7a858a5fc36a84bd03a440b4223472b"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"84199553a79d36fafe88321339a3f5b2bb71d6ae","unresolved":false,"context_lines":[{"line_number":478,"context_line":"      $ openstack accelerator device list -c uuid -c type | grep NVME"},{"line_number":479,"context_line":"      | 815146e7-48a3-4906-a0b5-47aee53abada | NVME |"},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"2. Use the Cyborg API directly to set the device to ``error`` state (requires"},{"line_number":482,"context_line":"   database access in dev):"},{"line_number":483,"context_line":""},{"line_number":484,"context_line":"   .. code-block:: console"}],"source_content_type":"text/x-rst","patch_set":18,"id":"81f92bf0_8dc99605","line":481,"updated":"2026-08-18 07:29:51.000000000","message":"Step 2 of the \u0027Trigger cleanup manually\u0027 test procedure reads \u0027Use the Cyborg API directly to set the device to error state (requires database access in dev)\u0027 but the accompanying command is a mysql UPDATE against the devices table; no API exists to set device_state to error (the only state-mutating endpoint is POST /clean, which requires error state already). The sentence contradicts the command it introduces.\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: A contributor reading the prose will look for an API call that does not exist; the intended meaning (directly modify the database, dev-only) is only recoverable from the command.\n\n**Recommendation**:\nReword to \u0027Directly set the device to error state in the database (dev-only, requires database access)\u0027 so the sentence matches the mysql command that follows.","commit_id":"4ac62f0cae017da2ae9fea4c42437277049b49d9"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d76461fa8477688d28aa8e0a48511373bc400223","unresolved":false,"context_lines":[{"line_number":490,"context_line":"3. Trigger cleanup (requires microversion 2.4):"},{"line_number":491,"context_line":""},{"line_number":492,"context_line":"   .. code-block:: console"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":"      $ source ~/devstack/openrc admin admin"},{"line_number":495,"context_line":"      $ TOKEN\u003d$(openstack token issue -c id -f value)"},{"line_number":496,"context_line":"      $ curl -s -X POST \\"}],"source_content_type":"text/x-rst","patch_set":27,"id":"b9d53888_063c3dff","line":493,"updated":"2026-09-01 09:52:34.000000000","message":"The step-by-step contributor guide (and the admin guide) show `curl -s -X POST ... $CYBORG_URL/v2/devices/\u003cuuid\u003e/clean`. `$CYBORG_URL` is not defined by `source openrc admin admin` (which exports OS_* variables), so copying the block verbatim sends the request to a relative URL and fails. The example also displays `HTTP/1.1 202 Accepted` as output, but `curl -s` prints nothing for a successful empty response; the status line only appears with `-i` or `-w \u0027%{http_code}\u0027`.\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: A contributor following the numbered test procedure verbatim gets a failed curl invocation or no visible confirmation and cannot tell whether the 202 was returned; minor because the example\u0027s intent is clear.\n\n**Recommendation**:\nResolve the endpoint first (e.g. `CYBORG_URL\u003d$(openstack catalog show accelerator ...)` or $OS_ACCELERATOR_API) and add `-w \u0027%{http_code}\\n\u0027` or `-i` so the 202 is actually shown, in both the contributor and admin examples.","commit_id":"dd0f8392948266425deb5e61a573dc6a82c1cb6f"}]}