)]}'
{"/COMMIT_MSG":[{"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":"980a541ffee8266502e9f4bd23d86ffb1dbfee19","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     8fb447a7 (Mark 2026.2 openstacksdk and dashboard specs implemented)"},{"line_number":2,"context_line":"Author:     Alfredo Moralejo \u003camoralej@redhat.com\u003e"},{"line_number":3,"context_line":"AuthorDate: 2026-10-28 13:55:43 +0100"},{"line_number":4,"context_line":"Commit:     Alfredo Moralejo \u003camoralej@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"0f2e1316_18783785","line":1,"updated":"2026-10-28 13:30:15.000000000","message":"The project spec template requires any specification proposing REST API changes to carry an APIImpact flag in the commit message so API reviewers can find the change via the documented Gerrit query. This spec proposes API-visible changes: audit ``parameters`` responses gain a reserved ``strategy_version`` key, strategies\u0027 ``parameters_spec`` responses show the spec version, and PATCH /v1/audits/\u003cuuid\u003e semantics change to re-resolve parameters against the current strategy spec. The commit message of this change contains no APIImpact footer.\n\n**Severity**: WARNING | **Confidence**: 0.82\n\n**Impact**: API-focused reviewers and future audits use the documented APIImpact Gerrit query to surface spec changes affecting the API. Without the flag this spec will not appear in that query, so the parameter-response and PATCH semantics changes may be approved without API review scrutiny and the search trail is lost permanently for the merged commit.\n\n**Suggestion**:\nWhen re-working the patchset, add an APIImpact footer to the commit message, e.g. \u0027APIImpact: audit parameters responses include the reserved strategy_version key, strategies parameters_spec shows the spec version, and PATCH /v1/audits re-resolves parameters against the current strategy spec\u0027.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"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":"0043b7d0e6bb1fb11c473c9c5d67f1360bcc1648","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     8fb447a7 (Mark 2026.2 openstacksdk and dashboard specs implemented)"},{"line_number":2,"context_line":"Author:     Alfredo Moralejo \u003camoralej@redhat.com\u003e"},{"line_number":3,"context_line":"AuthorDate: 2026-10-28 13:55:43 +0100"},{"line_number":4,"context_line":"Commit:     Alfredo Moralejo \u003camoralej@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"25fa828d_65e155fa","line":1,"updated":"2026-11-11 16:06:35.000000000","message":"The project spec template requires the APIImpact flag in the commit message when a specification proposes changes to the Watcher REST API, explicitly including \"changing parameters which can be returned or accepted\". This spec\u0027s REST API Impact section discloses exactly such changes: audit parameters responses will include the reserved strategy_version key, POST/PATCH calls supplying that key will fail validation, and the strategies API parameters_spec field will expose the spec version. The commit message for this change contains only Implements, Assisted-by, Change-Id, and Signed-off-by footers and no APIImpact flag.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Reviewers and API-focused watchers discover API-affecting spec reviews through the APIImpact message search documented in this repository. Without the flag, the disclosed audit parameters and parameters_spec changes may bypass that scrutiny, and the permanent change history understates the API impact of the design.\n\n**Suggestion**:\nAmend the commit message to add an APIImpact footer with a short description, for example: \"APIImpact: audit parameters responses include a reserved strategy_version key; that key is rejected in POST/PATCH parameters; strategy parameters_spec exposes the spec version\". No content change to the spec is required.","commit_id":"bfa8ea1686904a478d1c2430bf1e33951de10ba3"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"9fd6781b0fc275c7173922cc33de3b838f5f25fd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"86f11082_741fbc1f","updated":"2026-10-28 19:29:58.000000000","message":"I think that I agree with the general approach. Not sure about the migration process in the end, if we have a more detailed proposal on how to implement it.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"bfb90506_10a069e2","updated":"2026-11-05 18:57:14.000000000","message":"Thanks for adding more details. I think that the version-stepped transformations makes sense. It would be interesting to PoC that, by in theory should work\u003e\nAdded a question about external plugins handling.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"a2379b517ba3cd7cda6b0f07feb8cdab35f08412","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"dd50528c_7cecd379","in_reply_to":"bfb90506_10a069e2","updated":"2026-11-06 17:35:16.000000000","message":"I just sent https://review.opendev.org/q/topic:%22blueprint-update-goals-and-strategies-in-place%22 with an initial proposal.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"d7461053b80a92c66b7dcc897f3face6adadfccc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"7ec0b95c_53aed883","updated":"2026-11-12 18:02:34.000000000","message":"It looks good, I didn\u0027t check yet the implementation to see if I can spot any other corner case.\nThanks for the spec Alfredo","commit_id":"bfa8ea1686904a478d1c2430bf1e33951de10ba3"}],"specs/2027.1/approved/update-goals-and-strategies-in-place.rst":[{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"9fd6781b0fc275c7173922cc33de3b838f5f25fd","unresolved":true,"context_lines":[{"line_number":174,"context_line":"The required coding patterns for goal and strategy developers will be"},{"line_number":175,"context_line":"documented:"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* parameters spec changes must be backwards compatible (additive changes"},{"line_number":178,"context_line":"  only: new optional parameters with default values),"},{"line_number":179,"context_line":"* the parameters version marker must be bumped whenever the parameters spec"},{"line_number":180,"context_line":"  changes,"},{"line_number":181,"context_line":"* when a change cannot be expressed in an additive way, a migration hook"},{"line_number":182,"context_line":"  must be provided."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"Data Model Impact"},{"line_number":185,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8973c1d9_478030dd","line":182,"range":{"start_line":177,"start_character":0,"end_line":182,"end_character":19},"updated":"2026-10-28 19:29:58.000000000","message":"I think that we can better define this:\n1. if the parameters change is additive only, it will require at least a default value to be set. No migration hook is required, but a version bump is.\n2. if the parameters change is not backward compatible, a migration hook must be provided.\n\nis that it?","commit_id":"82d0a90566cd3bf91ef4353baa2fac0095a1c012"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5db60ac18bfeea57b1e610b47f6872e2cca58e18","unresolved":true,"context_lines":[{"line_number":174,"context_line":"The required coding patterns for goal and strategy developers will be"},{"line_number":175,"context_line":"documented:"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* parameters spec changes must be backwards compatible (additive changes"},{"line_number":178,"context_line":"  only: new optional parameters with default values),"},{"line_number":179,"context_line":"* the parameters version marker must be bumped whenever the parameters spec"},{"line_number":180,"context_line":"  changes,"},{"line_number":181,"context_line":"* when a change cannot be expressed in an additive way, a migration hook"},{"line_number":182,"context_line":"  must be provided."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"Data Model Impact"},{"line_number":185,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"90b34c36_ce91b768","line":182,"range":{"start_line":177,"start_character":0,"end_line":182,"end_character":19},"in_reply_to":"8973c1d9_478030dd","updated":"2026-10-30 16:52:30.000000000","message":"Is it better now?","commit_id":"82d0a90566cd3bf91ef4353baa2fac0095a1c012"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":false,"context_lines":[{"line_number":174,"context_line":"The required coding patterns for goal and strategy developers will be"},{"line_number":175,"context_line":"documented:"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* parameters spec changes must be backwards compatible (additive changes"},{"line_number":178,"context_line":"  only: new optional parameters with default values),"},{"line_number":179,"context_line":"* the parameters version marker must be bumped whenever the parameters spec"},{"line_number":180,"context_line":"  changes,"},{"line_number":181,"context_line":"* when a change cannot be expressed in an additive way, a migration hook"},{"line_number":182,"context_line":"  must be provided."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"Data Model Impact"},{"line_number":185,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5206f7d4_7c0d5a9b","line":182,"range":{"start_line":177,"start_character":0,"end_line":182,"end_character":19},"in_reply_to":"90b34c36_ce91b768","updated":"2026-11-05 18:57:14.000000000","message":"yes, thanks!","commit_id":"82d0a90566cd3bf91ef4353baa2fac0095a1c012"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"9fd6781b0fc275c7173922cc33de3b838f5f25fd","unresolved":true,"context_lines":[{"line_number":209,"context_line":"not actually provide any functionality to the user other than viewing"},{"line_number":210,"context_line":"the versions, a new microversion will not be created."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Alternatives"},{"line_number":213,"context_line":"------------"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Keep the current recreate-and-cancel behavior: rejected, it is the very"}],"source_content_type":"text/x-rst","patch_set":1,"id":"65ee21f0_f3defe00","line":212,"range":{"start_line":212,"start_character":0,"end_line":212,"end_character":12},"updated":"2026-10-28 19:29:58.000000000","message":"Nit, alternative: Include the parameters_version to Strategy and into the audit parameters, but instead of working with schema migrations, all Strategies would need to support current and older versions of its schema.\nWe don\u0027t need to think or include this one, TBH.","commit_id":"82d0a90566cd3bf91ef4353baa2fac0095a1c012"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5db60ac18bfeea57b1e610b47f6872e2cca58e18","unresolved":false,"context_lines":[{"line_number":209,"context_line":"not actually provide any functionality to the user other than viewing"},{"line_number":210,"context_line":"the versions, a new microversion will not be created."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Alternatives"},{"line_number":213,"context_line":"------------"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Keep the current recreate-and-cancel behavior: rejected, it is the very"}],"source_content_type":"text/x-rst","patch_set":1,"id":"641f9542_8127a9e8","line":212,"range":{"start_line":212,"start_character":0,"end_line":212,"end_character":12},"in_reply_to":"65ee21f0_f3defe00","updated":"2026-10-30 16:52:30.000000000","message":"Added.","commit_id":"82d0a90566cd3bf91ef4353baa2fac0095a1c012"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"9fd6781b0fc275c7173922cc33de3b838f5f25fd","unresolved":true,"context_lines":[{"line_number":78,"context_line":"As audit templates, audits and action plans keep referencing the same"},{"line_number":79,"context_line":"strategy and goal ids, no reassignment is needed anymore."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scoring engines keep their current synchronization behavior (recreation on"},{"line_number":82,"context_line":"modification) and are out of the scope of this change."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The current handling of goals and strategies that are removed from the"},{"line_number":85,"context_line":"codebase (soft-delete and cancellation of their audits) is unchanged: an"}],"source_content_type":"text/x-rst","patch_set":2,"id":"23b21eb9_3b8c4c67","line":82,"range":{"start_line":81,"start_character":0,"end_line":82,"end_character":54},"updated":"2026-10-28 19:29:58.000000000","message":"I would say that we need to think about Audit Scope too, something that is more likely to be changed.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5db60ac18bfeea57b1e610b47f6872e2cca58e18","unresolved":true,"context_lines":[{"line_number":78,"context_line":"As audit templates, audits and action plans keep referencing the same"},{"line_number":79,"context_line":"strategy and goal ids, no reassignment is needed anymore."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scoring engines keep their current synchronization behavior (recreation on"},{"line_number":82,"context_line":"modification) and are out of the scope of this change."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The current handling of goals and strategies that are removed from the"},{"line_number":85,"context_line":"codebase (soft-delete and cancellation of their audits) is unchanged: an"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8f013ced_e77d2320","line":82,"range":{"start_line":81,"start_character":0,"end_line":82,"end_character":54},"in_reply_to":"23b21eb9_3b8c4c67","updated":"2026-10-30 16:52:30.000000000","message":"You mean about changes in the schema of the AuditScope audit configs? schema for the scopes are defined in the collectors as in https://github.com/openstack/watcher/blob/39ef8100be68a7ec9e9055c10e7964f66e15297a/watcher/decision_engine/model/collector/nova.py#L46\n\nYes, we may adopt similar approach if we think we modify the scope schema in non-backwards compatible ways.\n\nHowever, note that, changes in the schema of the scopes are currently not cancelling audits iiuc, so i think it\u0027s out of the scope of this spec, imo. Said that, we probably may adopt similar approach as a new feature.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5e2a0f3a8555f4eb29f42ee8ba0534c28d668c4b","unresolved":true,"context_lines":[{"line_number":78,"context_line":"As audit templates, audits and action plans keep referencing the same"},{"line_number":79,"context_line":"strategy and goal ids, no reassignment is needed anymore."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scoring engines keep their current synchronization behavior (recreation on"},{"line_number":82,"context_line":"modification) and are out of the scope of this change."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The current handling of goals and strategies that are removed from the"},{"line_number":85,"context_line":"codebase (soft-delete and cancellation of their audits) is unchanged: an"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ca19d4ee_65b4daa2","line":82,"range":{"start_line":81,"start_character":0,"end_line":82,"end_character":54},"in_reply_to":"302538c5_7e064dda","updated":"2026-11-06 17:45:08.000000000","message":"I need to check on more detail, but my understanding is that, currently we only validate the scope schema when creating an audit template. When executing an audit, the get_scoped_model methods just read the content and process it as in https://github.com/openstack/watcher/blob/28da878b1ff1b4be820ef946af7c88563d43b9f3/watcher/decision_engine/scope/compute.py#L176\n\nYes, a non backwards compatible change in the scope may make a pre-existing audit to fail. However, i\u0027d keep the versioning of the scope out of the scope of this spec. We may implement a similar approach that the one for parameters later. \n\nAn easy win may be to implement scope validation before executing the audit and makint it to fail in a controlled way if it doesn\u0027t pass. We could implement that as a specless blueprint i.e.\n\nI had the feeling that scope schemas doesn\u0027t change much and it\u0027d be easier to maintain backwards compatibility there. Do you think we will hit incompatible changes soon?","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":true,"context_lines":[{"line_number":78,"context_line":"As audit templates, audits and action plans keep referencing the same"},{"line_number":79,"context_line":"strategy and goal ids, no reassignment is needed anymore."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scoring engines keep their current synchronization behavior (recreation on"},{"line_number":82,"context_line":"modification) and are out of the scope of this change."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The current handling of goals and strategies that are removed from the"},{"line_number":85,"context_line":"codebase (soft-delete and cancellation of their audits) is unchanged: an"}],"source_content_type":"text/x-rst","patch_set":2,"id":"302538c5_7e064dda","line":82,"range":{"start_line":81,"start_character":0,"end_line":82,"end_character":54},"in_reply_to":"8f013ced_e77d2320","updated":"2026-11-05 18:57:14.000000000","message":"Right, but we have the \"scope\" saved as an Audit attribute. If the scope is changed in a non-backward way, it would break continuous audits, no? So I believe tha is not cancelled by a mistake, but it shuold be too.\nWe may want to add at least a test that don\u0027t allow that to happen while we don\u0027t propose an similar upgrade approach for it. Until there we only propose backward compatible updates to it.\nWe should be able to include a continuous audit + scope test with grenade, to check if it continues to run.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"d7461053b80a92c66b7dcc897f3face6adadfccc","unresolved":true,"context_lines":[{"line_number":78,"context_line":"As audit templates, audits and action plans keep referencing the same"},{"line_number":79,"context_line":"strategy and goal ids, no reassignment is needed anymore."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scoring engines keep their current synchronization behavior (recreation on"},{"line_number":82,"context_line":"modification) and are out of the scope of this change."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The current handling of goals and strategies that are removed from the"},{"line_number":85,"context_line":"codebase (soft-delete and cancellation of their audits) is unchanged: an"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c4cead41_4187e5fd","line":82,"range":{"start_line":81,"start_character":0,"end_line":82,"end_character":54},"in_reply_to":"ca19d4ee_65b4daa2","updated":"2026-11-12 18:02:34.000000000","message":"As we discussed durint the watcher meeting today, the team agree that this can be out of the scope.\nIn case you provide a new PS, I think that worth mentioning the scope too since it is part of the Audit and is a resource that can break existing audits durint the upgrade. Also note that today there is no especial treatment for audit scope in syncer.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"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":"980a541ffee8266502e9f4bd23d86ffb1dbfee19","unresolved":false,"context_lines":[{"line_number":196,"context_line":"REST API Impact"},{"line_number":197,"context_line":"---------------"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"No new or modified REST API endpoints are required."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"The only visible change is that the audit ``parameters`` field includes"},{"line_number":202,"context_line":"the reserved version marker key in responses. As the parameter validation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2bb60941_120b4f82","line":199,"updated":"2026-10-28 13:30:15.000000000","message":"The REST API Impact section states \u0027No new or modified REST API endpoints are required\u0027 and \u0027The only visible change is that the audit parameters field includes the reserved version marker key in responses\u0027. Both statements conflict with the document itself: the Proposed Change modifies the behavior of the existing PATCH /v1/audits/\u003cuuid\u003e endpoint (re-resolve parameters against the current strategy spec and update the stored version), and the same REST section names a second visible change, the strategies ``parameters_spec`` field showing the spec version. The section also does not address GET-then-PATCH round-tripping, which now fails because responses contain the reserved key that POST/PATCH reject.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: The REST API Impact section is the primary input for API review of a spec. Presenting a semantics change to an existing endpoint and two response-body changes as \u0027no modified endpoints\u0027 and \u0027the only visible change\u0027 can let the PATCH behavior change escape API scrutiny and misleads reviewers about the true API surface of the feature.\n\n**Suggestion**:\nRewrite the section to say that no new endpoints are added, but existing endpoint behavior and response bodies change: audit ``parameters`` gains the reserved ``strategy_version`` key, strategies ``parameters_spec`` shows the spec version, and PATCH /v1/audits re-resolves parameters against the current strategy spec. State explicitly how GET-then-PATCH round-trips are affected by rejection of the reserved key.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"9fd6781b0fc275c7173922cc33de3b838f5f25fd","unresolved":true,"context_lines":[{"line_number":300,"context_line":""},{"line_number":301,"context_line":"``Step 2: Implement online data migration``"},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* Implement the ``migrate_parameters()`` hook in ``BaseStrategy``."},{"line_number":304,"context_line":"* Add a common migration hook to add version marker to ``parameters``"},{"line_number":305,"context_line":"  which does not have it and revalidate and resolve all parameters from"},{"line_number":306,"context_line":"  the current version."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":"``Step 3: Modify strategies update behavior on Syncer``"},{"line_number":309,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"59edfdd2_b60e9a55","line":306,"range":{"start_line":303,"start_character":0,"end_line":306,"end_character":22},"updated":"2026-10-28 19:29:58.000000000","message":"Do we have an idea how it is going to be implemented? Just wondering if we have other places that have similar migrations as examples.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":false,"context_lines":[{"line_number":300,"context_line":""},{"line_number":301,"context_line":"``Step 2: Implement online data migration``"},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* Implement the ``migrate_parameters()`` hook in ``BaseStrategy``."},{"line_number":304,"context_line":"* Add a common migration hook to add version marker to ``parameters``"},{"line_number":305,"context_line":"  which does not have it and revalidate and resolve all parameters from"},{"line_number":306,"context_line":"  the current version."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":"``Step 3: Modify strategies update behavior on Syncer``"},{"line_number":309,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5d12da5d_3b7fabb1","line":306,"range":{"start_line":303,"start_character":0,"end_line":306,"end_character":22},"in_reply_to":"4c557f1a_d38fb3d1","updated":"2026-11-05 18:57:14.000000000","message":"Done","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5db60ac18bfeea57b1e610b47f6872e2cca58e18","unresolved":true,"context_lines":[{"line_number":300,"context_line":""},{"line_number":301,"context_line":"``Step 2: Implement online data migration``"},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* Implement the ``migrate_parameters()`` hook in ``BaseStrategy``."},{"line_number":304,"context_line":"* Add a common migration hook to add version marker to ``parameters``"},{"line_number":305,"context_line":"  which does not have it and revalidate and resolve all parameters from"},{"line_number":306,"context_line":"  the current version."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":"``Step 3: Modify strategies update behavior on Syncer``"},{"line_number":309,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"4c557f1a_d38fb3d1","line":306,"range":{"start_line":303,"start_character":0,"end_line":306,"end_character":22},"in_reply_to":"59edfdd2_b60e9a55","updated":"2026-10-30 16:52:30.000000000","message":"I\u0027ve added some details about the proposed implementation approach.","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"9fd6781b0fc275c7173922cc33de3b838f5f25fd","unresolved":true,"context_lines":[{"line_number":322,"context_line":""},{"line_number":323,"context_line":"None."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":"Testing"},{"line_number":326,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":327,"context_line":""},{"line_number":328,"context_line":"* Unit and functional tests are sufficient to validate both the behavior of"}],"source_content_type":"text/x-rst","patch_set":2,"id":"80778b33_0c4634ef","line":325,"range":{"start_line":325,"start_character":0,"end_line":325,"end_character":7},"updated":"2026-10-28 19:29:58.000000000","message":"Makes sense to have a workable example? like Dummy strategy where we rename a field?","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":false,"context_lines":[{"line_number":322,"context_line":""},{"line_number":323,"context_line":"None."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":"Testing"},{"line_number":326,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":327,"context_line":""},{"line_number":328,"context_line":"* Unit and functional tests are sufficient to validate both the behavior of"}],"source_content_type":"text/x-rst","patch_set":2,"id":"16ee63f5_cf967c4a","line":325,"range":{"start_line":325,"start_character":0,"end_line":325,"end_character":7},"in_reply_to":"7973b3c8_4aa869b5","updated":"2026-11-05 18:57:14.000000000","message":"Done","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5db60ac18bfeea57b1e610b47f6872e2cca58e18","unresolved":true,"context_lines":[{"line_number":322,"context_line":""},{"line_number":323,"context_line":"None."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":"Testing"},{"line_number":326,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":327,"context_line":""},{"line_number":328,"context_line":"* Unit and functional tests are sufficient to validate both the behavior of"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7973b3c8_4aa869b5","line":325,"range":{"start_line":325,"start_character":0,"end_line":325,"end_character":7},"in_reply_to":"80778b33_0c4634ef","updated":"2026-10-30 16:52:30.000000000","message":"Added. My idea is to implement the end-to-end test in functional tests by updating the dummy strategy (probably monkey patching it)","commit_id":"357f601d13e7b5fa4c96fa745ac72a060a75e60a"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"7dc3db9678cfe2a450c97773226f120f0e316f75","unresolved":true,"context_lines":[{"line_number":97,"context_line":"recorded together with a version marker of the strategy:"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* Strategies declare a version marker of their parameters spec: a"},{"line_number":100,"context_line":"  ``version`` field in the dict returned by the ``get_schema()``"},{"line_number":101,"context_line":"  method, bumped by the developer whenever the parameters spec changes."},{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9b164733_064ba265","line":100,"updated":"2026-11-04 11:45:48.000000000","message":"how will this work? Will we add the `version` as an optional field in the schema to avoid issues with validation? That would show it to the user I think for example in the dashboard, which would be weird to show an option that the user can\u0027t actually use","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"aa84e9faad6d8e636309cba0f05cf77894eabcfa","unresolved":false,"context_lines":[{"line_number":97,"context_line":"recorded together with a version marker of the strategy:"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* Strategies declare a version marker of their parameters spec: a"},{"line_number":100,"context_line":"  ``version`` field in the dict returned by the ``get_schema()``"},{"line_number":101,"context_line":"  method, bumped by the developer whenever the parameters spec changes."},{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"2640c3aa_54e75be8","line":100,"in_reply_to":"9193c764_a181b4dd","updated":"2026-11-05 19:03:30.000000000","message":"I was worried that maybe that could interfere with the schema validation, but I did a quick test locally and it should not be a problem. The other doubt I had was wrt to showing the version in API responses, but I see this is explicitly mentioned in the REST API section, so I\u0027m ok with that","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"0dcd073d5fb7e367f85b93eaf1be60b902b74f80","unresolved":true,"context_lines":[{"line_number":97,"context_line":"recorded together with a version marker of the strategy:"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* Strategies declare a version marker of their parameters spec: a"},{"line_number":100,"context_line":"  ``version`` field in the dict returned by the ``get_schema()``"},{"line_number":101,"context_line":"  method, bumped by the developer whenever the parameters spec changes."},{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9193c764_a181b4dd","line":100,"in_reply_to":"9b164733_064ba265","updated":"2026-11-04 13:24:43.000000000","message":"What i was thinking is to add the `version` as top level field of the get_spec() response, but not in the \"properties\" dict field. From the strategies api response, it\u0027d be something like:\n\n```\n    \"parameters_spec\": {\n        \"version\": \"1.0\",\n        \"properties\": {\n            \"para2\": {\n                \"default\": \"hello\",\n                \"type\": \"string\",\n                \"description\": \"string parameter example\"\n            },\n            \"para1\": {\n                \"maximum\": 10.2,\n                \"type\": \"number\",\n                \"minimum\": 1.0,\n                \"description\": \"number parameter example\",\n                \"default\": 3.2\n            }\n        }\n    },\n```","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"7dc3db9678cfe2a450c97773226f120f0e316f75","unresolved":true,"context_lines":[{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* For audits with a predefined strategy, the API will persist the version"},{"line_number":106,"context_line":"  marker of the strategy in a ``strategy_version`` field in the"},{"line_number":107,"context_line":"  ``parameters`` JSON column together with the resolved parameters (user"},{"line_number":108,"context_line":"  values plus default values) at creation or update."}],"source_content_type":"text/x-rst","patch_set":3,"id":"06c50eb8_9ee974e3","line":105,"updated":"2026-11-04 11:45:48.000000000","message":"I\u0027m not sure I understand this paragraph, `predefined` here means audits created before an upgrade, or audits that are created requesting an specific strategy?","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"0dcd073d5fb7e367f85b93eaf1be60b902b74f80","unresolved":true,"context_lines":[{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* For audits with a predefined strategy, the API will persist the version"},{"line_number":106,"context_line":"  marker of the strategy in a ``strategy_version`` field in the"},{"line_number":107,"context_line":"  ``parameters`` JSON column together with the resolved parameters (user"},{"line_number":108,"context_line":"  values plus default values) at creation or update."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fe957df8_41b49a3b","line":105,"in_reply_to":"06c50eb8_9ee974e3","updated":"2026-11-04 13:24:43.000000000","message":"Yes, this wording is missleading. Watcher API allows to create an audit defining only the goal, not the strategy. In that case the decision-engine lists all the strategies for the goal and picks the first one. In those cases, we can not set the parameters as picking the strategy is at execution time.\n\nHere, by \"audits with a predefined strategy\", means audits which have been assigned a strategy when creating it via direct audit creation strategy parameter or using an audittemplate with goal and strategy. This is the most common case (actually, i\u0027d say all the docs refer to setting the strategy when creating an audit) but the api also supports defining an audit with goal-only.\n\nWhat could be a better wording?","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"a2379b517ba3cd7cda6b0f07feb8cdab35f08412","unresolved":true,"context_lines":[{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* For audits with a predefined strategy, the API will persist the version"},{"line_number":106,"context_line":"  marker of the strategy in a ``strategy_version`` field in the"},{"line_number":107,"context_line":"  ``parameters`` JSON column together with the resolved parameters (user"},{"line_number":108,"context_line":"  values plus default values) at creation or update."}],"source_content_type":"text/x-rst","patch_set":3,"id":"8346ae84_1be668f6","line":105,"in_reply_to":"08545c3c_b9890aed","updated":"2026-11-06 17:35:16.000000000","message":"Thanks, I will modify in next PS.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"cf6022109edad3feb0953cad0d97c8c7525f5905","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* For audits with a predefined strategy, the API will persist the version"},{"line_number":106,"context_line":"  marker of the strategy in a ``strategy_version`` field in the"},{"line_number":107,"context_line":"  ``parameters`` JSON column together with the resolved parameters (user"},{"line_number":108,"context_line":"  values plus default values) at creation or update."}],"source_content_type":"text/x-rst","patch_set":3,"id":"b29edbcb_847f367a","line":105,"in_reply_to":"8346ae84_1be668f6","updated":"2026-11-11 15:56:42.000000000","message":"Done","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"aa84e9faad6d8e636309cba0f05cf77894eabcfa","unresolved":true,"context_lines":[{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* For audits with a predefined strategy, the API will persist the version"},{"line_number":106,"context_line":"  marker of the strategy in a ``strategy_version`` field in the"},{"line_number":107,"context_line":"  ``parameters`` JSON column together with the resolved parameters (user"},{"line_number":108,"context_line":"  values plus default values) at creation or update."}],"source_content_type":"text/x-rst","patch_set":3,"id":"08545c3c_b9890aed","line":105,"in_reply_to":"fe957df8_41b49a3b","updated":"2026-11-05 19:03:30.000000000","message":"```suggestion\n* For audits created selecting a specific strategy, the API will persist the version\n```\n\nI think something like this conveys better the intended meaning","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":true,"context_lines":[{"line_number":102,"context_line":"  The marker makes it possible to detect, for each audit, whether its"},{"line_number":103,"context_line":"  snapshot was taken with an older parameters spec."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* For audits with a predefined strategy, the API will persist the version"},{"line_number":106,"context_line":"  marker of the strategy in a ``strategy_version`` field in the"},{"line_number":107,"context_line":"  ``parameters`` JSON column together with the resolved parameters (user"},{"line_number":108,"context_line":"  values plus default values) at creation or update."}],"source_content_type":"text/x-rst","patch_set":3,"id":"52375f4a_b1bf35a9","line":105,"in_reply_to":"fe957df8_41b49a3b","updated":"2026-11-05 18:57:14.000000000","message":"yeah, maybe you can start mentioning that setting an audit\u0027s strategy is optional.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"7dc3db9678cfe2a450c97773226f120f0e316f75","unresolved":true,"context_lines":[{"line_number":110,"context_line":"* Once created, the ``parameters`` column of an audit must not be"},{"line_number":111,"context_line":"  modified unless:"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  - it is explicitly modified by a PATCH call to the"},{"line_number":114,"context_line":"    ``/v1/audits/\u003cuuid\u003e`` endpoint. In that case, the strategy version"},{"line_number":115,"context_line":"    is updated to the current one and the rest of the parameters are"},{"line_number":116,"context_line":"    resolved against the current version of the strategy spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9d47d532_57bb031f","line":113,"updated":"2026-11-04 11:45:48.000000000","message":"the PATCH operation will trigger an online data migration when updating the parameters?","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0ed83f1f1012ea01dd3c8d9fa643f0c2ffd673cd","unresolved":true,"context_lines":[{"line_number":110,"context_line":"* Once created, the ``parameters`` column of an audit must not be"},{"line_number":111,"context_line":"  modified unless:"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  - it is explicitly modified by a PATCH call to the"},{"line_number":114,"context_line":"    ``/v1/audits/\u003cuuid\u003e`` endpoint. In that case, the strategy version"},{"line_number":115,"context_line":"    is updated to the current one and the rest of the parameters are"},{"line_number":116,"context_line":"    resolved against the current version of the strategy spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"b56653e4_2b11fddf","line":113,"in_reply_to":"77437ac6_3dea2c98","updated":"2026-11-09 11:55:10.000000000","message":"ok, that\u0027s an important clarification, updates are only done via decision-engine restart. That is clearly explained in the next section, what I think originally confused me is the phrase \n```\n In that case, the strategy version\n    is updated to the current one and the rest of the parameters are\n    resolved against the current version of the strategy spec.\n```\nbecase as you mention the strategy version will have been previously updated by the decision engine, so  I think a better phrasing would be something like:\n\n```\n In that case, the strategy version\n    will have been updated to the current one by the decision-engine and the rest of the parameters are\n    resolved against the current version of the strategy spec.\n```","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"a2379b517ba3cd7cda6b0f07feb8cdab35f08412","unresolved":true,"context_lines":[{"line_number":110,"context_line":"* Once created, the ``parameters`` column of an audit must not be"},{"line_number":111,"context_line":"  modified unless:"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  - it is explicitly modified by a PATCH call to the"},{"line_number":114,"context_line":"    ``/v1/audits/\u003cuuid\u003e`` endpoint. In that case, the strategy version"},{"line_number":115,"context_line":"    is updated to the current one and the rest of the parameters are"},{"line_number":116,"context_line":"    resolved against the current version of the strategy spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"77437ac6_3dea2c98","line":113,"in_reply_to":"8f9ad96d_501fae5a","updated":"2026-11-06 17:35:16.000000000","message":"Let\u0027s say from my previous example. A new version 1.2 is removing parameter `foo`. For that case, the developer should add a upgrade hook in the `update_parameters` method of the strategy removing it from the `parameters` dicts of the existing Audits. When the cluster admin updates watcher including that strategy, at start of the decision-engine, the sync method will apply the `update_parameters` to the audit, so the new content of the Audit parameters will be:\n\n```\nstrategy_version: 1.2,\nbar: false\n```\n\nSo the pre-existing audit has updated version and removed the `foo` parameter so it passes validation and can work.\n\nIf a user then patches the Audit X with `parameters: {\u0027bar\u0027: true}`, the api will apply that patch together with the validation and the resulting Audit parameters would be:\n\n```\nstrategy_version: 1.2,\nbar: true\n```\n\nA key part here is that, in order to update an strategy, a restart of the watcher services will always be required and the decision-engine will take care of the required parameters updates at start to make it consistent with current strategy. From that moment, any POST or PATCH call should be working with a content of parameters that has already been migrated and validated with current version of the strategy.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"0dcd073d5fb7e367f85b93eaf1be60b902b74f80","unresolved":true,"context_lines":[{"line_number":110,"context_line":"* Once created, the ``parameters`` column of an audit must not be"},{"line_number":111,"context_line":"  modified unless:"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  - it is explicitly modified by a PATCH call to the"},{"line_number":114,"context_line":"    ``/v1/audits/\u003cuuid\u003e`` endpoint. In that case, the strategy version"},{"line_number":115,"context_line":"    is updated to the current one and the rest of the parameters are"},{"line_number":116,"context_line":"    resolved against the current version of the strategy spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"b1246995_cddcf41d","line":113,"in_reply_to":"9d47d532_57bb031f","updated":"2026-11-04 13:24:43.000000000","message":"not an online data migration, but when a patch call is done modifying the \"parameters\" section, watcher api will validate and re-resolve all the parameters (including the new ones that may have been added) against the current strategy spec so it will update the `strategy_version` field. So, let\u0027s say Audit X has been created for an strategy `test` with version 1.0 which only has parameter foo with default true. Initially, parameters content is:\n\n```\nstrategy_version: 1.0,\nfoo: true\n```\n\nLater, new version 1.1 is created adding parameter bar with default false. I patch Audit X with `parameters: {\u0027foo\u0027: false}`. The new content of the Audit parameters will be:\n\n```\nstrategy_version: 1.1,\nfoo: false\nbar: false\n```\n\nSo, effectively, a patch call in an audit will update its parameter spec to the latest version.\n\nNote that no online data migration (update_parameters) should be needed in a patch call. If needed it should be have been executed in a previous decision-engine restart.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"98b1cfbe2d0291fd706d1fda97d4841b208216a3","unresolved":true,"context_lines":[{"line_number":110,"context_line":"* Once created, the ``parameters`` column of an audit must not be"},{"line_number":111,"context_line":"  modified unless:"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  - it is explicitly modified by a PATCH call to the"},{"line_number":114,"context_line":"    ``/v1/audits/\u003cuuid\u003e`` endpoint. In that case, the strategy version"},{"line_number":115,"context_line":"    is updated to the current one and the rest of the parameters are"},{"line_number":116,"context_line":"    resolved against the current version of the strategy spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"8f9ad96d_501fae5a","line":113,"in_reply_to":"b1246995_cddcf41d","updated":"2026-11-06 08:18:08.000000000","message":"I see. That will work well with additive changes, but what about version bumps that remove parameters? Then we would need a call to update_parameters like in the data migration or we would end up with invalid parameters no?","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"cf6022109edad3feb0953cad0d97c8c7525f5905","unresolved":true,"context_lines":[{"line_number":110,"context_line":"* Once created, the ``parameters`` column of an audit must not be"},{"line_number":111,"context_line":"  modified unless:"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  - it is explicitly modified by a PATCH call to the"},{"line_number":114,"context_line":"    ``/v1/audits/\u003cuuid\u003e`` endpoint. In that case, the strategy version"},{"line_number":115,"context_line":"    is updated to the current one and the rest of the parameters are"},{"line_number":116,"context_line":"    resolved against the current version of the strategy spec."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fbb4101f_c96c5205","line":113,"in_reply_to":"b56653e4_2b11fddf","updated":"2026-11-11 15:56:42.000000000","message":"That actually depends. Note that only the strategies with backwards incompatible changes will implement actual modifications in update_parameters() and will update the parameters fields. And not for all the version updates, only when needed. so the sentence `the strategy version will have been updated to the current one by the decision-engine...` is not exact. I\u0027ve updated the wording and the order, which i think makes it more clear. Let me know what do you think","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":true,"context_lines":[{"line_number":138,"context_line":"added to ``update_parameters()`` to modify the ``parameters`` JSON as"},{"line_number":139,"context_line":"needed."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Each strategy class manages the evolution of its own parameters spec,"},{"line_number":142,"context_line":"whose version is declared in a ``version`` field of the dict returned"},{"line_number":143,"context_line":"by its ``get_schema()`` method, bumped by the developer whenever the"},{"line_number":144,"context_line":"parameters spec changes. All in-tree strategies start at ``\"1.0\"``."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"To migrate the stored parameters of the existing audits,"},{"line_number":147,"context_line":"``BaseStrategy`` is extended with an overridable"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ba140fa5_b8644fdc","line":144,"range":{"start_line":141,"start_character":0,"end_line":144,"end_character":67},"updated":"2026-11-05 18:57:14.000000000","message":"How are we going to handle external Strategies? I propose that, if an strategy doesn\u0027t return a ``version`` and changes are detected, we continue with the current approach of cancelling the audits. External strategies will need to follow the same pattern and mark their schema with a version.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"d7461053b80a92c66b7dcc897f3face6adadfccc","unresolved":false,"context_lines":[{"line_number":138,"context_line":"added to ``update_parameters()`` to modify the ``parameters`` JSON as"},{"line_number":139,"context_line":"needed."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Each strategy class manages the evolution of its own parameters spec,"},{"line_number":142,"context_line":"whose version is declared in a ``version`` field of the dict returned"},{"line_number":143,"context_line":"by its ``get_schema()`` method, bumped by the developer whenever the"},{"line_number":144,"context_line":"parameters spec changes. All in-tree strategies start at ``\"1.0\"``."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"To migrate the stored parameters of the existing audits,"},{"line_number":147,"context_line":"``BaseStrategy`` is extended with an overridable"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ddd5b316_cdf7a621","line":144,"range":{"start_line":141,"start_character":0,"end_line":144,"end_character":67},"in_reply_to":"5f3f3e54_2d7b71ce","updated":"2026-11-12 18:02:34.000000000","message":"Approach 1 is fine, since we want to rework this part and avoid cancelling and creating new Strategies to replace the existing ones.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"cf6022109edad3feb0953cad0d97c8c7525f5905","unresolved":true,"context_lines":[{"line_number":138,"context_line":"added to ``update_parameters()`` to modify the ``parameters`` JSON as"},{"line_number":139,"context_line":"needed."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Each strategy class manages the evolution of its own parameters spec,"},{"line_number":142,"context_line":"whose version is declared in a ``version`` field of the dict returned"},{"line_number":143,"context_line":"by its ``get_schema()`` method, bumped by the developer whenever the"},{"line_number":144,"context_line":"parameters spec changes. All in-tree strategies start at ``\"1.0\"``."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"To migrate the stored parameters of the existing audits,"},{"line_number":147,"context_line":"``BaseStrategy`` is extended with an overridable"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5f3f3e54_2d7b71ce","line":144,"range":{"start_line":141,"start_character":0,"end_line":144,"end_character":67},"in_reply_to":"8422c3f0_c4a55198","updated":"2026-11-11 15:56:42.000000000","message":"Added information in PS4. Let me know what do you think about it.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"a2379b517ba3cd7cda6b0f07feb8cdab35f08412","unresolved":true,"context_lines":[{"line_number":138,"context_line":"added to ``update_parameters()`` to modify the ``parameters`` JSON as"},{"line_number":139,"context_line":"needed."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Each strategy class manages the evolution of its own parameters spec,"},{"line_number":142,"context_line":"whose version is declared in a ``version`` field of the dict returned"},{"line_number":143,"context_line":"by its ``get_schema()`` method, bumped by the developer whenever the"},{"line_number":144,"context_line":"parameters spec changes. All in-tree strategies start at ``\"1.0\"``."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"To migrate the stored parameters of the existing audits,"},{"line_number":147,"context_line":"``BaseStrategy`` is extended with an overridable"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f9ff81d9_8ce708ab","line":144,"range":{"start_line":141,"start_character":0,"end_line":144,"end_character":67},"in_reply_to":"ba140fa5_b8644fdc","updated":"2026-11-06 17:35:16.000000000","message":"That\u0027s a good question. Options:\n\n1. We leave the Audit untouched. CONTINUOUS audits will continue active. However, the decision-engine AuditHandler checks if the parameters content pass schema validation, so it will be fine while the changes are backwards compatible. When an audit fails to validate, it will be set to FAILED and leave a clear error in the `status_message`.\n\n2. Audits for unversioned strategies are cancelled. Current behaviour, although we still do in-place update of the strategy in the database and will not create a new UUID (I don\u0027t see the point on recreating it with a new UUID as it\u0027s done now).\n\nI\u0027d tend to option 1 although it changes the current behavior, i think that by pre-validating the parameters in Audit execution, we provide a smooth path for backward compatible changes which i feel is actually a more expected behavior.","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0ed83f1f1012ea01dd3c8d9fa643f0c2ffd673cd","unresolved":true,"context_lines":[{"line_number":138,"context_line":"added to ``update_parameters()`` to modify the ``parameters`` JSON as"},{"line_number":139,"context_line":"needed."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Each strategy class manages the evolution of its own parameters spec,"},{"line_number":142,"context_line":"whose version is declared in a ``version`` field of the dict returned"},{"line_number":143,"context_line":"by its ``get_schema()`` method, bumped by the developer whenever the"},{"line_number":144,"context_line":"parameters spec changes. All in-tree strategies start at ``\"1.0\"``."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"To migrate the stored parameters of the existing audits,"},{"line_number":147,"context_line":"``BaseStrategy`` is extended with an overridable"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8422c3f0_c4a55198","line":144,"range":{"start_line":141,"start_character":0,"end_line":144,"end_character":67},"in_reply_to":"f9ff81d9_8ce708ab","updated":"2026-11-09 11:55:10.000000000","message":"+1 for option 1. While it is technically not backwards compatible, the difference is minor, the audits continue stopping, but now the user will have better visibility as to why","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"7dc3db9678cfe2a450c97773226f120f0e316f75","unresolved":true,"context_lines":[{"line_number":277,"context_line":"  complexity and the functionality required for the cases actually faced"},{"line_number":278,"context_line":"  during strategy development."},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"* Online data migrations could be done on audit execution instead of at"},{"line_number":281,"context_line":"  the decision-engine sync start: rejected, as doing them at sync limits"},{"line_number":282,"context_line":"  the migration logic execution to just once at service startup and only"},{"line_number":283,"context_line":"  for the audits in PENDING, ONGOING or SUSPENDED status, instead of on"}],"source_content_type":"text/x-rst","patch_set":3,"id":"35491390_13c58f8b","line":280,"updated":"2026-11-04 11:45:48.000000000","message":"+1, centralizing this responsibility in one place simplifies the logic and the upgrade impact significantly","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"4f980037f0ee40ce432fc2bbf552415165894de3","unresolved":true,"context_lines":[{"line_number":334,"context_line":""},{"line_number":335,"context_line":"No database migration is required. Audits created before the upgrade get"},{"line_number":336,"context_line":"their version marker added as described in the Data Model Impact section."},{"line_number":337,"context_line":"After the upgrade, upgrades of Watcher or strategy plugins no longer cancel"},{"line_number":338,"context_line":"audits."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"Implementation"},{"line_number":341,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"56f89f08_54e091a0","line":338,"range":{"start_line":337,"start_character":0,"end_line":338,"end_character":7},"updated":"2026-11-05 18:57:14.000000000","message":"It depends, will that work for external strategies too?","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"d7461053b80a92c66b7dcc897f3face6adadfccc","unresolved":false,"context_lines":[{"line_number":334,"context_line":""},{"line_number":335,"context_line":"No database migration is required. Audits created before the upgrade get"},{"line_number":336,"context_line":"their version marker added as described in the Data Model Impact section."},{"line_number":337,"context_line":"After the upgrade, upgrades of Watcher or strategy plugins no longer cancel"},{"line_number":338,"context_line":"audits."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"Implementation"},{"line_number":341,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b53daeaa_5a5adacc","line":338,"range":{"start_line":337,"start_character":0,"end_line":338,"end_character":7},"in_reply_to":"56f89f08_54e091a0","updated":"2026-11-12 18:02:34.000000000","message":"Done","commit_id":"e9e466bd44f4aa62306a5f8a13dc6e8f6d4feea0"}]}