)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"76dee696034d95bbbeb103ebdcc310c3df282e82","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"4af8bb8e_861dd932","updated":"2025-12-16 16:41:49.000000000","message":"@smooney@redhat.com thanks for the throuough review, you raised some good points. I\u0027ll try to go over them in more detail tomorrow, but I\u0027m thinking that it might be better to abandon this spec for this cycle and get a new for next cycle to extend strategies with some kind of versioning that would help track these kind of changes more carefully and handle the upgrade impact properly","commit_id":"77208b6ed11e3b150630718ddcb7dabbc7b1d694"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f2098d8493b2e9d007d8ce1c3e77498a5eabdc4d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"75335f30_e527921c","in_reply_to":"4af8bb8e_861dd932","updated":"2025-12-16 17:14:58.000000000","message":"+1 that fine with me.\ni woudl prefer not to rush it so im ok to take the time to get it right.","commit_id":"77208b6ed11e3b150630718ddcb7dabbc7b1d694"}],"specs/2026.1/approved/rename_zone_migration_parameters.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":53,"context_line":"* ``dst_pool`` → ``dst_storage_host``"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"To ensure backward compatibility, the implementation will support both the old"},{"line_number":56,"context_line":"and new field names during the current cycle. This should ensure that resuming"},{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df09ad58_26b77984","line":56,"updated":"2025-11-04 12:42:00.000000000","message":"so this is probly the most contovial point\n\nwhen and if we can ever stop supportign the old names.\n\nat a minium if we are to drop this supprot we would ahve to deprecate it in a slup from an upstream stand point before this could be remvoed but im not sure we should ever remove the supprot for the old name.\n\nthe related question is shoudl this require a micoversion or do we consier the subfield of the parmaters to be unversioned.\n\nthey do have a json schema today but that schma its elf does not have a verion and stragies and goal are both plugable. so that would imply that the additon or modification of one shoudl not require an api microversion.\n\nthat does nto mean we can/should make backward incompatible cahnge to them or that they shoudl not be versioed at all.\n\n\nmy personal prefence woudl be to keep the field for more then one release i.e. 1-2 slrups then consider it at the api level. at the db level we can be more agressive and translate the old name into the new name and the same at the object level.\n\neffectively we would allow it at the api but translate it internally.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":53,"context_line":"* ``dst_pool`` → ``dst_storage_host``"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"To ensure backward compatibility, the implementation will support both the old"},{"line_number":56,"context_line":"and new field names during the current cycle. This should ensure that resuming"},{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"199e80da_9f6fd3a7","line":56,"in_reply_to":"69ee32f9_e5a94723","updated":"2025-12-15 13:34:25.000000000","message":"Acknowledged","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"10fe4e8b5f835229d92405cff4108a2f492db231","unresolved":true,"context_lines":[{"line_number":53,"context_line":"* ``dst_pool`` → ``dst_storage_host``"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"To ensure backward compatibility, the implementation will support both the old"},{"line_number":56,"context_line":"and new field names during the current cycle. This should ensure that resuming"},{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"69ee32f9_e5a94723","line":56,"in_reply_to":"739de8f1_32b65433","updated":"2025-11-07 15:58:46.000000000","message":"it comes donw to the api contract\n\nwhile we may not require a microverion for this we need to alwasy supprot the old format unless we raise our min microveriosn so we shoudl not plan to actully remove the old field unelssl we are goign to force everyone to use a new microversoin break backward compatioablity.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":53,"context_line":"* ``dst_pool`` → ``dst_storage_host``"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"To ensure backward compatibility, the implementation will support both the old"},{"line_number":56,"context_line":"and new field names during the current cycle. This should ensure that resuming"},{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"739de8f1_32b65433","line":56,"in_reply_to":"df09ad58_26b77984","updated":"2025-11-07 15:36:26.000000000","message":"the current release is a slurp one, so policy-wise planning to remove them in the next slurp would be ok right? Regardless, we can decide to drop the plan to remove them from the spec, as mentioned in the next comment, it should have no maintenace burden to keep the deprecated fields","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"},{"line_number":60,"context_line":"old parameter names will be removed."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The zone migration strategy schema will be modified to accept both old and new"},{"line_number":63,"context_line":"field names:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b98265ee_0abc3ab0","line":60,"updated":"2025-11-04 12:42:00.000000000","message":"so i think marking it as deprecated makes sense but setting a target release to remove it im less convinced about.\n\nif it cost us little to maintain then the cost of braking existing user outweighs the benefit","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"},{"line_number":60,"context_line":"old parameter names will be removed."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The zone migration strategy schema will be modified to accept both old and new"},{"line_number":63,"context_line":"field names:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffdf4df9_17cc1587","line":60,"in_reply_to":"b98265ee_0abc3ab0","updated":"2025-11-07 15:36:26.000000000","message":"it\u0027s true that once the internal translation mechanism is implemented there no cost of mantaining, so I\u0027m ok taking out the plan to remove the fields from the spec.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"},{"line_number":60,"context_line":"old parameter names will be removed."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The zone migration strategy schema will be modified to accept both old and new"},{"line_number":63,"context_line":"field names:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7bf592eb_dbe34dd3","line":60,"in_reply_to":"efaeca11_55df716c","updated":"2025-12-15 13:34:25.000000000","message":"well its not really a mateer of cost.\n\nwe have to supprot old microversion forecver unless we create a new major release of an api or we raise the min microverison. as i noted on other spec nova is now on 2.100 and has never removed an old microversion or raised its min so doing it is a high barier. ill mark this resolved for now.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"2b39eb69ba96bab8c97b5a86a583e623aa386bff","unresolved":true,"context_lines":[{"line_number":57,"context_line":"any continuous audit stored in the database before the upgrade is possible."},{"line_number":58,"context_line":"Both the old parameter names and the new will be supported for the current and"},{"line_number":59,"context_line":"next cycle, with the old names marked as deprecated. After the two cycles, the"},{"line_number":60,"context_line":"old parameter names will be removed."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The zone migration strategy schema will be modified to accept both old and new"},{"line_number":63,"context_line":"field names:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"efaeca11_55df716c","line":60,"in_reply_to":"ffdf4df9_17cc1587","updated":"2025-11-28 11:28:53.000000000","message":"+1 to maintain the mechanism. It\u0027d be good if we can make something reusable across strategies in case we need it in some other strategy.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* Accept both ``src_pool`` and ``src_storage_host`` (mutually exclusive)"},{"line_number":66,"context_line":"* Accept both ``dst_pool`` and ``dst_storage_host`` (mutually exclusive)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"However, creating an audit using the old names will result in"},{"line_number":69,"context_line":"deprecation warnings being emitted, and the documentation will be updated to"},{"line_number":70,"context_line":"show the new names as preferred."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9685df94_4e8bafa1","line":67,"updated":"2025-11-04 12:42:00.000000000","message":"+1 on makeing them mutally exclusive","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"4420d740edc8cb68fe310c5f57a6704cbba3b156","unresolved":false,"context_lines":[{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* Accept both ``src_pool`` and ``src_storage_host`` (mutually exclusive)"},{"line_number":66,"context_line":"* Accept both ``dst_pool`` and ``dst_storage_host`` (mutually exclusive)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"However, creating an audit using the old names will result in"},{"line_number":69,"context_line":"deprecation warnings being emitted, and the documentation will be updated to"},{"line_number":70,"context_line":"show the new names as preferred."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7bc73229_e7aa3143","line":67,"in_reply_to":"94fd1249_3e6c8f3c","updated":"2025-11-28 12:16:35.000000000","message":"Done","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* Accept both ``src_pool`` and ``src_storage_host`` (mutually exclusive)"},{"line_number":66,"context_line":"* Accept both ``dst_pool`` and ``dst_storage_host`` (mutually exclusive)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"However, creating an audit using the old names will result in"},{"line_number":69,"context_line":"deprecation warnings being emitted, and the documentation will be updated to"},{"line_number":70,"context_line":"show the new names as preferred."}],"source_content_type":"text/x-rst","patch_set":2,"id":"94fd1249_3e6c8f3c","line":67,"in_reply_to":"9685df94_4e8bafa1","updated":"2025-11-07 15:36:26.000000000","message":"Acknowledged","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"However, creating an audit using the old names will result in"},{"line_number":69,"context_line":"deprecation warnings being emitted, and the documentation will be updated to"},{"line_number":70,"context_line":"show the new names as preferred."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"When running an audit, a new function will be called to check if the strategy"},{"line_number":73,"context_line":"has any deprecated parameters, and will do a data migration on load for audits"}],"source_content_type":"text/x-rst","patch_set":2,"id":"de7b4b9d_ed36d7c4","line":70,"updated":"2025-11-04 12:42:00.000000000","message":"im not convince this is correct\n\nWarning are meant to indicate that the opentack installer administrator that is tasked with deploying/maintain the cloud has an action to take.\n\nwhile the person crating the audits has the admin rule they are really a cloud end user and they will not have access to the logs to see the warning.\n\nas such i think this warning is not useful and would actually just be noise\n\nwe coudl emit an info level log when transfroming the old name to the new name but wraning need to be actionable by the infra admin.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"However, creating an audit using the old names will result in"},{"line_number":69,"context_line":"deprecation warnings being emitted, and the documentation will be updated to"},{"line_number":70,"context_line":"show the new names as preferred."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"When running an audit, a new function will be called to check if the strategy"},{"line_number":73,"context_line":"has any deprecated parameters, and will do a data migration on load for audits"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ce04a945_22babf0f","line":70,"in_reply_to":"6ff178f4_18fbe93c","updated":"2025-12-15 13:34:25.000000000","message":"i would not do more then a debug log. ill resolve this for now and we can discuss in the implementation.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"However, creating an audit using the old names will result in"},{"line_number":69,"context_line":"deprecation warnings being emitted, and the documentation will be updated to"},{"line_number":70,"context_line":"show the new names as preferred."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"When running an audit, a new function will be called to check if the strategy"},{"line_number":73,"context_line":"has any deprecated parameters, and will do a data migration on load for audits"}],"source_content_type":"text/x-rst","patch_set":2,"id":"6ff178f4_18fbe93c","line":70,"in_reply_to":"de7b4b9d_ed36d7c4","updated":"2025-11-07 15:36:26.000000000","message":"that is a good point about the logs, we might want to print some warning in the client, but maybe as you said an info log would be enough. For now I removed the mention of the warning and we can discuss here if we want to log anything or not","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":74,"context_line":"using the deprecated fields, updating the audit in the database with the new"},{"line_number":75,"context_line":"version of the deprecated field names. The ``BaseStrategy`` class will have an"},{"line_number":76,"context_line":"empty version of this method and it will be overloaded in the strategies that"},{"line_number":77,"context_line":"have deprecated fields."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1542bc8f_1587f912","line":77,"updated":"2025-11-04 12:42:00.000000000","message":"ok we can do that we dont really need to have the migrate on load be a part of the intergace fo the class as it shuld happen intenrnally but we can do that.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":74,"context_line":"using the deprecated fields, updating the audit in the database with the new"},{"line_number":75,"context_line":"version of the deprecated field names. The ``BaseStrategy`` class will have an"},{"line_number":76,"context_line":"empty version of this method and it will be overloaded in the strategies that"},{"line_number":77,"context_line":"have deprecated fields."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f26c5d6_21c077b2","line":77,"in_reply_to":"1542bc8f_1587f912","updated":"2025-11-07 15:36:26.000000000","message":"I proposed to add it to the interface for two reasons:\n1. it would make it quite obvious in code what to do to rename parameters\n2. we could call it just after the schema validation in https://github.com/openstack/watcher/blob/74efcbf9992b0ffee1fcd5bc72b8b4f7963a4166/watcher/decision_engine/strategy/context/default.py#L64 and before feeding the audit parameters to the strategy, that way the parameters are already sanitized and the handling in the strategy would be simpler.\n\nThat said, it could be handled internally in the strategy, I wouldn\u0027t be completely opposed to that","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":74,"context_line":"using the deprecated fields, updating the audit in the database with the new"},{"line_number":75,"context_line":"version of the deprecated field names. The ``BaseStrategy`` class will have an"},{"line_number":76,"context_line":"empty version of this method and it will be overloaded in the strategies that"},{"line_number":77,"context_line":"have deprecated fields."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"93c304af_b057ffe3","line":77,"in_reply_to":"1f26c5d6_21c077b2","updated":"2025-12-15 17:51:46.000000000","message":"thinking about this more we cant actully do this.\n\nwe cant save the converted object back as it woudl break anyone who depens on the old names.\n\nif we want to do this we need to have a api microversoin to allow getting the object with the old names or it breaks api compatiably\n\n\nbasically if a continuous audit is created with 2025.1 and then you upgrade to 2026.1 and do a show on the audit or actions the api respocne shoudl remain the same unless there is a new api microversion. in which case it shoudl only change for the new version.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"03ca1c60f06ac8e3f694f27c6a96d550e3439d56","unresolved":true,"context_lines":[{"line_number":74,"context_line":"using the deprecated fields, updating the audit in the database with the new"},{"line_number":75,"context_line":"version of the deprecated field names. The ``BaseStrategy`` class will have an"},{"line_number":76,"context_line":"empty version of this method and it will be overloaded in the strategies that"},{"line_number":77,"context_line":"have deprecated fields."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4737653e_2fc1e139","line":77,"in_reply_to":"93c304af_b057ffe3","updated":"2025-12-17 19:34:39.000000000","message":"I think that it is ok to do the conversion internally, for the strategy algorithym, but I\u0027m against updating the database with the new name, it can break existing intehrations (as sean mentioned) and it would be confusing for user point of view. We could do the update once we remove the old param names, for the existing audits.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":90,"context_line":"No database schema changes are required. Audit parameters are stored as JSON"},{"line_number":91,"context_line":"in the ``parameters`` column (``JSONEncodedDict`` type), which provides"},{"line_number":92,"context_line":"flexibility for this type of change. Strategy schemas are also stored as"},{"line_number":93,"context_line":"``JSONEncodedDict`` in the ``parameters_spec`` column."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Similarly, there is no change to the either of the ``Audit`` or ``Strategy``"},{"line_number":96,"context_line":"objects. Audits store the parameters in a ``wfields.FlexibleDictField`` field,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"aab5e96f_8d15a723","line":93,"updated":"2025-11-04 12:42:00.000000000","message":"it is however a change to the data store in teh db requiring a migration and a change to the json schema for those json blobs\n\nso its correct not to list this as None","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":false,"context_lines":[{"line_number":90,"context_line":"No database schema changes are required. Audit parameters are stored as JSON"},{"line_number":91,"context_line":"in the ``parameters`` column (``JSONEncodedDict`` type), which provides"},{"line_number":92,"context_line":"flexibility for this type of change. Strategy schemas are also stored as"},{"line_number":93,"context_line":"``JSONEncodedDict`` in the ``parameters_spec`` column."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Similarly, there is no change to the either of the ``Audit`` or ``Strategy``"},{"line_number":96,"context_line":"objects. Audits store the parameters in a ``wfields.FlexibleDictField`` field,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9b6e462a_7c9c5dac","line":93,"in_reply_to":"aab5e96f_8d15a723","updated":"2025-11-07 15:36:26.000000000","message":"Acknowledged","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":95,"context_line":"Similarly, there is no change to the either of the ``Audit`` or ``Strategy``"},{"line_number":96,"context_line":"objects. Audits store the parameters in a ``wfields.FlexibleDictField`` field,"},{"line_number":97,"context_line":"and the Strategy uses the same type for the ``parameters_spec`` field. This"},{"line_number":98,"context_line":"type allows and addition of a new field in the schema without any conflict."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0848d62f_ba58f441","line":98,"updated":"2025-11-04 12:42:00.000000000","message":"taht ture but at the cost of being less well typed.\n\nthis si ok for a generic Strategy base class but we shoudl consider if we want to be strictre for the concreate Strategy in terms of how we defein the class.\n\nwe shoudl at a minium do a schmea check on modifying this filed.\n\nthe base statgey ovo uses a generic parmspec \n\nhttps://github.com/openstack/watcher/blob/master/watcher/objects/strategy.py#L40\n\nbut i dont think that is really correct for the concreate instnece and the stragy classes shoudl really inherit form the ovo objects\n\nhttps://github.com/openstack/watcher/blob/master/watcher/decision_engine/strategy/strategies/base.py#L121\n\nthis is existing technical debt so im not sure if it makes sen to adress in this spec or not\n\nwaht i woudl prefer is to to have a new ovo feild type that is a DictWithSchema type or similar that will enfoce the parmaters confrom to the schema definiton.\n\nthat woudl allow the base class ot have any parmaters but hte concreate ones to have only the valid ones.\n\nnova made this trasnstaion a very long time ago \n\nhttps://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/resource-objects.html\nit took several year to complete the work \nhttps://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/convert-consoles-to-objects.html\n\nbut i stongly dislike that we have 4 diffent indepenent defintion of what a stragey is\n\nthe api, the db model, the object model and the class in the descison engine\n\nthe way this si ment to work is the db model and db api defien the low level primitive for how the stragy is stored in the db.\n\nthe watcher obejct provides the higher level public interface to a logical stragy \n\nthe api translates the json request into a watcher object and then calls save on teh object to save it to the db. (the api shoudl not know baout the db model or methosd or call them) the desion engine constuct the strage object form the object by usign methd liek get_by_uuid ectra to retive them and the object handels all data migration ectra internal in it object form db methods.\n\nthe base autis shoudl not have \nseperate field for the input parmater and autid scope\n\nhttps://github.com/openstack/watcher/blob/master/watcher/decision_engine/strategy/strategies/base.py#L157C6-L158\n\nit shoudl be constuceted with an instnace of https://github.com/openstack/watcher/blob/master/watcher/objects/audit.py\n\nit also shoudl not have the models as sertat fiels it whoudl be pass an interface to a model manager or similar.\n\nthere are a lot of thing wrong with the curent class stucure\nbut im alos unsure when we want to pay down that technical debt","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":95,"context_line":"Similarly, there is no change to the either of the ``Audit`` or ``Strategy``"},{"line_number":96,"context_line":"objects. Audits store the parameters in a ``wfields.FlexibleDictField`` field,"},{"line_number":97,"context_line":"and the Strategy uses the same type for the ``parameters_spec`` field. This"},{"line_number":98,"context_line":"type allows and addition of a new field in the schema without any conflict."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bb67d42c_15256173","line":98,"in_reply_to":"0848d62f_ba58f441","updated":"2025-11-07 15:36:26.000000000","message":"I 100% agree with what you wrote here. I had similar thought when writing the spec, that we probably should change the strategy objects and define the particular strategy as ovos. Tbh I did not think about all the particulars of how such an implementation would work, you have gone into more detail here, but I think that would really quickly blow up in complexity, that is why I did not mention it here at all, I don\u0027t think we should try to cover it in this spec. I\u0027m not sure what would be the best way to keep a record this tech debt, it might merit a discussion in the next PTG tbh.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Similarly, there is no change to the either of the ``Audit`` or ``Strategy``"},{"line_number":96,"context_line":"objects. Audits store the parameters in a ``wfields.FlexibleDictField`` field,"},{"line_number":97,"context_line":"and the Strategy uses the same type for the ``parameters_spec`` field. This"},{"line_number":98,"context_line":"type allows and addition of a new field in the schema without any conflict."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"}],"source_content_type":"text/x-rst","patch_set":2,"id":"34fb53d1_67cd4492","line":98,"in_reply_to":"bb67d42c_15256173","updated":"2025-12-15 13:34:25.000000000","message":"Acknowledged","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":102,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"de3d0ecf_707d3ed1","line":102,"updated":"2025-11-04 12:42:00.000000000","message":"+1\n\nwe may want to extend the watcher-dbmange cli with an online-migration command to allow manually migrating all the audits in the db\n\nwe woudl need to do that eventually if we were to ever drop the old fields and move the on load code path.\n\nthe onlone behaivor is fine for things liek contiuous audits but we need to also cather for completed oneshot audtis as well and im not sure just doing it as part fo an audit list will perfome well.\n\nhttps://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L597-L655","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":102,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c53a8eb6_2f647c2f","line":102,"in_reply_to":"297c876e_1437132b","updated":"2025-12-15 13:34:25.000000000","message":"the would get migrated if we were to list/read them form the API on load.\notherwise it would not be done until they are eventually deleted","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"754bb59d1593ccaaacc482de03785299fcc06231","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":102,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"297c876e_1437132b","line":102,"in_reply_to":"299c18ca_3de0ac37","updated":"2025-12-05 09:09:42.000000000","message":"I think the automatic inline migration is good for existing ongoing continuous audits in a migration case. For stored completed audits, it\u0027d be fine to not touch them or require manual migration step.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":102,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d8e6fa43_f95d4ebd","line":102,"in_reply_to":"c53a8eb6_2f647c2f","updated":"2025-12-15 17:51:46.000000000","message":"se my comment above, thinking about this again this has upgrade problems.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"03ca1c60f06ac8e3f694f27c6a96d550e3439d56","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":102,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"e90b083a_e1b05888","line":102,"in_reply_to":"d8e6fa43_f95d4ebd","updated":"2025-12-17 19:34:39.000000000","message":"I\u0027m against the automatic migration. If we had microversions for these parameters, that would be fine, since you could read from db and convert back to the old names, if the request comes from a old microversion. We may want to convert all once we remove the old names, but even then, it can break existing integrations. I\u0027m in favor of having the db-manage operation, so users/admin can decide to convert them manually","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":101,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":102,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"299c18ca_3de0ac37","line":102,"in_reply_to":"de3d0ecf_707d3ed1","updated":"2025-11-07 15:36:26.000000000","message":"good point, I\u0027ve added a sentence mentioning manual migrations and I can implement that as a follow-up to the main implementation","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b45ea2212a27f2cd7201b82d96943312208d942d","unresolved":true,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"* API requests using old field names continue to work (with deprecation"},{"line_number":114,"context_line":"  warnings)"},{"line_number":115,"context_line":"* API requests using new field names work immediately"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"No API microversion increase is needed because:"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"08864b3a_e81eec53","line":115,"updated":"2025-11-04 12:42:00.000000000","message":"so the api microverion contract effectivly state that we can never break a old microverson and we never stop supproting them unless we raise our min micorveriosn\n\nas far as im aware no project that uses microversion ever raised the min version but i could be wrong.\n\nefectly if a request is supproted with 1.6 today, that request shoudl work in 10 year time with 1.6 unless that feature is entirly removed\n\ni.e. if the staegey is entrily remvoed we are allow to fail that request but if it still exist we shoudl still suprpot it unless we have raised our min microversion above 1.6","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"0668558301bd9abc2afb8ccf7caf92a511109ea5","unresolved":true,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"* API requests using old field names continue to work (with deprecation"},{"line_number":114,"context_line":"  warnings)"},{"line_number":115,"context_line":"* API requests using new field names work immediately"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"No API microversion increase is needed because:"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"59e11111_d1883f3a","line":115,"in_reply_to":"08864b3a_e81eec53","updated":"2025-11-07 15:36:26.000000000","message":"I\u0027ve deleted any mention of stopping support of the old name so this  would not be a problem.","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"* API requests using old field names continue to work (with deprecation"},{"line_number":114,"context_line":"  warnings)"},{"line_number":115,"context_line":"* API requests using new field names work immediately"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"No API microversion increase is needed because:"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ab5a9d97_b972225a","line":115,"in_reply_to":"59e11111_d1883f3a","updated":"2025-12-15 13:34:25.000000000","message":"Done","commit_id":"76d775b16099d6ac043880e5944bf14d7694d17f"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"2b39eb69ba96bab8c97b5a86a583e623aa386bff","unresolved":true,"context_lines":[{"line_number":24,"context_line":"each element can specify source and destination storage locations for volume"},{"line_number":25,"context_line":"migrations. The current field names are:"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"* ``src_pool``: Source storage pool from which volumes migrate"},{"line_number":28,"context_line":"* ``dst_pool``: Destination storage pool to which volumes migrate"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"However, these names are misleading because:"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3ddf281e_74ba2074","line":28,"range":{"start_line":27,"start_character":0,"end_line":28,"end_character":65},"updated":"2025-11-28 11:28:53.000000000","message":"I wonder if we should use this renaming oportunity to also change the parallelization parameters parallel_total, parallel_per_node and parallel_per_pool which are not really about parallelization but about max limits.\n\nThe actual parallelization will be defined by the weight planner parameters which is the planner set for this strategy.","commit_id":"d54c6b4dbeb70381fd79e1e410224bec0905352f"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"4420d740edc8cb68fe310c5f57a6704cbba3b156","unresolved":true,"context_lines":[{"line_number":24,"context_line":"each element can specify source and destination storage locations for volume"},{"line_number":25,"context_line":"migrations. The current field names are:"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"* ``src_pool``: Source storage pool from which volumes migrate"},{"line_number":28,"context_line":"* ``dst_pool``: Destination storage pool to which volumes migrate"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"However, these names are misleading because:"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ada9fda4_3e6694b9","line":28,"range":{"start_line":27,"start_character":0,"end_line":28,"end_character":65},"in_reply_to":"3ddf281e_74ba2074","updated":"2025-11-28 12:16:35.000000000","message":"that\u0027s a good point, it would be a good improvement. I\u0027ll expand the spec to cover those parameters as well","commit_id":"d54c6b4dbeb70381fd79e1e410224bec0905352f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":24,"context_line":"each element can specify source and destination storage locations for volume"},{"line_number":25,"context_line":"migrations. The current field names are:"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"* ``src_pool``: Source storage pool from which volumes migrate"},{"line_number":28,"context_line":"* ``dst_pool``: Destination storage pool to which volumes migrate"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"However, these names are misleading because:"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"10ce09c1_1199648e","line":28,"range":{"start_line":27,"start_character":0,"end_line":28,"end_character":65},"in_reply_to":"ada9fda4_3e6694b9","updated":"2025-12-15 13:34:25.000000000","message":"Done","commit_id":"d54c6b4dbeb70381fd79e1e410224bec0905352f"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"754bb59d1593ccaaacc482de03785299fcc06231","unresolved":true,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Top-level strategy parameters:"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* ``parallel_total`` → ``limit_actions_total``"},{"line_number":93,"context_line":"* ``parallel_per_node`` → ``limit_actions_per_node``"},{"line_number":94,"context_line":"* ``parallel_per_pool`` → ``limit_actions_per_pool``"},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"00588f52_999a2916","line":92,"range":{"start_line":92,"start_character":25,"end_line":92,"end_character":44},"updated":"2025-12-05 09:09:42.000000000","message":"I\u0027s say the `max_` preffix is more commonly used in parameter names to express upper limits that `limit_` in watcher (max_audit_workers, query_max_retries, max_limit, etc...).\n\nAlso, we may consider changing the default behavior being not limit (sorry for increasing the scope of the spec on each review :) )","commit_id":"b1374199611308af7fcc72e2d4f13311fb256f2e"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"e166889aeb607fb8850e466d0025395e4c9b67e7","unresolved":true,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Top-level strategy parameters:"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* ``parallel_total`` → ``limit_actions_total``"},{"line_number":93,"context_line":"* ``parallel_per_node`` → ``limit_actions_per_node``"},{"line_number":94,"context_line":"* ``parallel_per_pool`` → ``limit_actions_per_pool``"},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"1e300272_9f754f0a","line":92,"range":{"start_line":92,"start_character":25,"end_line":92,"end_character":44},"in_reply_to":"00588f52_999a2916","updated":"2025-12-05 15:54:05.000000000","message":"that\u0027s right, I changed the name to `max_actions_total`, `max_actions_per_node` and `max_actions_per_pool`. About the default behaviour, I don\u0027t think that we should  incorporate any behaviour change into this spec.","commit_id":"b1374199611308af7fcc72e2d4f13311fb256f2e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Top-level strategy parameters:"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* ``parallel_total`` → ``limit_actions_total``"},{"line_number":93,"context_line":"* ``parallel_per_node`` → ``limit_actions_per_node``"},{"line_number":94,"context_line":"* ``parallel_per_pool`` → ``limit_actions_per_pool``"},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a7aa03f_d91ed0cd","line":92,"range":{"start_line":92,"start_character":25,"end_line":92,"end_character":44},"in_reply_to":"1e300272_9f754f0a","updated":"2025-12-15 13:34:25.000000000","message":"Done","commit_id":"b1374199611308af7fcc72e2d4f13311fb256f2e"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"754bb59d1593ccaaacc482de03785299fcc06231","unresolved":true,"context_lines":[{"line_number":146,"context_line":"type allows and addition of a new field in the schema without any conflict."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":149,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":150,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":151,"context_line":"* The watcher-dbmanage tool will be expanded to be able to migrate all existing"},{"line_number":152,"context_line":"  audits in the database to updated finished oneshot audits or archived audits"}],"source_content_type":"text/x-rst","patch_set":4,"id":"17c1e6b9_a109542b","line":149,"range":{"start_line":149,"start_character":0,"end_line":149,"end_character":2},"updated":"2025-12-05 09:09:42.000000000","message":"I\u0027d do New audits created with **both new or old field names** will have new names stored.","commit_id":"b1374199611308af7fcc72e2d4f13311fb256f2e"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"e166889aeb607fb8850e466d0025395e4c9b67e7","unresolved":true,"context_lines":[{"line_number":146,"context_line":"type allows and addition of a new field in the schema without any conflict."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":149,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":150,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":151,"context_line":"* The watcher-dbmanage tool will be expanded to be able to migrate all existing"},{"line_number":152,"context_line":"  audits in the database to updated finished oneshot audits or archived audits"}],"source_content_type":"text/x-rst","patch_set":4,"id":"35467a46_708bf8f2","line":149,"range":{"start_line":149,"start_character":0,"end_line":149,"end_character":2},"in_reply_to":"17c1e6b9_a109542b","updated":"2025-12-05 15:54:05.000000000","message":"Thanks, I\u0027ll clarify the sentence. I considered new audits using old field names to be covered by the next bullet point, but I\u0027ll correct that","commit_id":"b1374199611308af7fcc72e2d4f13311fb256f2e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":true,"context_lines":[{"line_number":146,"context_line":"type allows and addition of a new field in the schema without any conflict."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":149,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":150,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":151,"context_line":"* The watcher-dbmanage tool will be expanded to be able to migrate all existing"},{"line_number":152,"context_line":"  audits in the database to updated finished oneshot audits or archived audits"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9e76f5e5_a66b4c69","line":149,"range":{"start_line":149,"start_character":0,"end_line":149,"end_character":2},"in_reply_to":"35467a46_708bf8f2","updated":"2025-12-15 13:34:25.000000000","message":"this shoudl be a api error.\n\nfor any one microversion we shoudl only supprot the new or old name\n\nif you send both then it shoudl be a 400 bad request","commit_id":"b1374199611308af7fcc72e2d4f13311fb256f2e"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"a6aebf101b21224f365f7337f03b9d27aae54844","unresolved":true,"context_lines":[{"line_number":146,"context_line":"type allows and addition of a new field in the schema without any conflict."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"* Old audits will continue to have old field names in their stored parameters"},{"line_number":149,"context_line":"* New audits created with new field names will have new names stored"},{"line_number":150,"context_line":"* Audits using the old names will be migrated on load to use the new ones"},{"line_number":151,"context_line":"* The watcher-dbmanage tool will be expanded to be able to migrate all existing"},{"line_number":152,"context_line":"  audits in the database to updated finished oneshot audits or archived audits"}],"source_content_type":"text/x-rst","patch_set":4,"id":"84bcd636_77427397","line":149,"range":{"start_line":149,"start_character":0,"end_line":149,"end_character":2},"in_reply_to":"9e76f5e5_a66b4c69","updated":"2025-12-15 14:43:01.000000000","message":"do you mean passing both old and new names in an audit should be a 400, or that only the old or new names should be supported at any point in time?","commit_id":"b1374199611308af7fcc72e2d4f13311fb256f2e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/watcher/+spec/rename-zone-migration-parameters"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"The Zone migration strategy currently uses parameter names that can be"},{"line_number":14,"context_line":"confusing for users. This spec proposes renaming multiple parameters to"},{"line_number":15,"context_line":"better represent their purpose and data format:"},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"* ``src_pool`` and ``dst_pool`` in the ``storage_pools`` array, which actually"},{"line_number":18,"context_line":"  contain full storage host identifiers in the format ``host@backend#pool``,"},{"line_number":19,"context_line":"  not just pool names"},{"line_number":20,"context_line":"* ``parallel_total``, ``parallel_per_node``, and ``parallel_per_pool``, which"},{"line_number":21,"context_line":"  control the number of actions per action plan or host rather than parallelism"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Problem description"},{"line_number":24,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":25,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"6e1a50a9_8b713ad2","line":22,"range":{"start_line":13,"start_character":1,"end_line":22,"end_character":1},"updated":"2025-12-15 17:51:46.000000000","message":"there is a lot of duplciation between here and the problem description section.\n\n```suggestion\nThe Zone migration strategy currently uses parameter names that can be\nconfusing for users. This spec proposes renaming multiple parameters to\nbetter represent their purpose\n```","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"76dee696034d95bbbeb103ebdcc310c3df282e82","unresolved":true,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/watcher/+spec/rename-zone-migration-parameters"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"The Zone migration strategy currently uses parameter names that can be"},{"line_number":14,"context_line":"confusing for users. This spec proposes renaming multiple parameters to"},{"line_number":15,"context_line":"better represent their purpose and data format:"},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"* ``src_pool`` and ``dst_pool`` in the ``storage_pools`` array, which actually"},{"line_number":18,"context_line":"  contain full storage host identifiers in the format ``host@backend#pool``,"},{"line_number":19,"context_line":"  not just pool names"},{"line_number":20,"context_line":"* ``parallel_total``, ``parallel_per_node``, and ``parallel_per_pool``, which"},{"line_number":21,"context_line":"  control the number of actions per action plan or host rather than parallelism"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Problem description"},{"line_number":24,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":25,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ed41bc99_799d8a13","line":22,"range":{"start_line":13,"start_character":1,"end_line":22,"end_character":1},"in_reply_to":"6e1a50a9_8b713ad2","updated":"2025-12-16 16:41:49.000000000","message":"thanks, done!","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":97,"context_line":"and new parameter names. This should ensure that resuming any continuous audit"},{"line_number":98,"context_line":"stored in the database before the upgrade is possible."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"The zone migration strategy schema will be modified to accept both old and new"},{"line_number":101,"context_line":"parameter names:"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"**Storage Pool Fields** (mutually exclusive pairs):"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* Accept both ``src_pool`` and ``src_storage_host``"},{"line_number":106,"context_line":"* Accept both ``dst_pool`` and ``dst_storage_host``"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"**Action Rate Limit Parameters** (mutually exclusive pairs):"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"* Accept both ``parallel_total`` and ``max_actions_total``"},{"line_number":111,"context_line":"* Accept both ``parallel_per_node`` and ``max_actions_per_node``"},{"line_number":112,"context_line":"* Accept both ``parallel_per_pool`` and ``max_actions_per_pool``"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"When running an audit, a new function will be called to check if the strategy"},{"line_number":115,"context_line":"has any deprecated parameters, and will do a data migration on load for audits"}],"source_content_type":"text/x-rst","patch_set":5,"id":"8d14414c_117170d8","line":112,"range":{"start_line":100,"start_character":0,"end_line":112,"end_character":64},"updated":"2025-12-15 17:51:46.000000000","message":"this is feels incorrect to me but im not entirly sure what the best way to fix it is.\n\nso what i am trying to reconsile is normally i woudl expect a change like this to require a new api microversion. if we did have a new api microversion we would excplive accpte the old parmamater in the old microverion and the new name in the new microversion. The reason we are not requireing a new microversion is because stragies are plugable.\n\ni am wondering if we need to extened all stragies with a verion number and version the schemas fo the strategies based on that. even if we dont requrie a new microverion for the api i dont think we shoudl suprpot mixing any the diffent mutlally exclusive pairs. i would prefer if require exclusively the old names for all parameter or exclusively the new names within any instance of a strategy object\n\nwhat im trying to reconcile is does that mean we also need to enforce that at the audit level in the input parameters or if its ok to enforce that later when we translate the input parameters into strategy objects\n\nhttps://github.com/openstack/watcher/blob/master/watcher/objects/strategy.py#L40\n\nwe dont need to resovle this now as we extended the Host maintenance strategy to supprot disabling live migration and codle mighrtation in \n\nhttps://review.opendev.org/c/openstack/watcher-specs/+/943873\n\nso we have made this type of change without versioning the schemas but long term that feel incorrect to me and we should correct it eventually.\n\nfor any given stragiy for the same api micoverion teh content of the response shoudl not very between openstack cloud based on the openstack release.\n\nits fine for it to vary for diffent strgies but for a specific microverison the same request and response shoudl not change based on the version installed on the server and this change breaks that api convention.","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":166,"context_line":"* API requests using new field names work immediately"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"No API microversion increase is needed because:"},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"* This is a strategy parameter change, not an API schema change"},{"line_number":171,"context_line":"* The API already accepts arbitrary JSON for strategy parameters"},{"line_number":172,"context_line":"* Backward compatibility is maintained through the strategy\u0027s validation logic"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"Security impact"},{"line_number":175,"context_line":"---------------"},{"line_number":176,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"0639b62e_18d9be0b","line":173,"range":{"start_line":169,"start_character":0,"end_line":173,"end_character":1},"updated":"2025-12-15 17:51:46.000000000","message":"that is not quite true.\n\neach audit reference a specific strategy and each strategy has a jsonscema for the parameters\n\nso its not true to say it arbitrary JSON\n\nso while it does not directly modify the rest API schema it is an API change.\n\nunlike https://review.opendev.org/c/openstack/watcher-specs/+/943873/6/specs/2025.2/approved/host-maintenance-strategy-disable-migration.rst#24\n\nwe are not just adding new parameter we are \"removing\" old ones. by deprecating them so we cant apply the same logic.\n\nwe can only proceed with this if we preserve the format that the client provided indefinitely.\n\nsince we have to assume that they may be using an old rest client indefinitely.\n\ninternally we can use the new names but we cant transfrom the data like i ourtinly tought we coudl because that woudl alter te respocne if you did an audit show which will break old rest client that dont support teh new paramter names.","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":193,"context_line":""},{"line_number":194,"context_line":"The Horizon dashboard may need updates to:"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* Use new field names in audit creation forms"},{"line_number":197,"context_line":"* Update help text and tooltips to reference new names"},{"line_number":198,"context_line":"* Display deprecation notices when old names are detected in existing audits"},{"line_number":199,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"31b877d8_bfc06c69","line":196,"updated":"2025-12-15 17:51:46.000000000","message":"it can only do this if they are reported via the api.\n\nwe also dont currently ahve a way to annotate files as deprecated or what they are replaceed by so it cannot know that it should use the new names.","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* Use new field names in audit creation forms"},{"line_number":197,"context_line":"* Update help text and tooltips to reference new names"},{"line_number":198,"context_line":"* Display deprecation notices when old names are detected in existing audits"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"These changes should be coordinated but are not strictly required for this"},{"line_number":201,"context_line":"spec\u0027s implementation."}],"source_content_type":"text/x-rst","patch_set":5,"id":"6881cf78_c9ef212b","line":198,"updated":"2025-12-15 17:51:46.000000000","message":"again it cant actuly do this based on teh current stragy show responce\n\nhttps://docs.openstack.org/api-ref/resource-optimization/#id77\n\nthe parameters_spec which is the json schema for the stragy does not have any concept of deprecation.\n\nwe woudl need to modify the format to includ that and then modify the horizon plugin to parse and respect that.","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"657c47f3e2e5d5b331b97b338e2ae48f2324c7ba","unresolved":true,"context_lines":[{"line_number":200,"context_line":"These changes should be coordinated but are not strictly required for this"},{"line_number":201,"context_line":"spec\u0027s implementation."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"**Documentation Updates**"},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"The following documentation must be updated:"},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"* ``doc/source/strategies/zone_migration.rst`` - Update parameter table to"},{"line_number":208,"context_line":"  show new names as primary and old names as deprecated"},{"line_number":209,"context_line":"* User guides - Update all examples to use new field names"},{"line_number":210,"context_line":"* API documentation - Add notes about the deprecation"},{"line_number":211,"context_line":"* Release notes - Document the change and migration timeline"},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"Performance Impact"},{"line_number":214,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"b3befc63_b5b87686","line":211,"range":{"start_line":203,"start_character":0,"end_line":211,"end_character":60},"updated":"2025-12-15 17:51:46.000000000","message":"this shoudl be in the documentation impact section","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"76dee696034d95bbbeb103ebdcc310c3df282e82","unresolved":true,"context_lines":[{"line_number":200,"context_line":"These changes should be coordinated but are not strictly required for this"},{"line_number":201,"context_line":"spec\u0027s implementation."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"**Documentation Updates**"},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"The following documentation must be updated:"},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"* ``doc/source/strategies/zone_migration.rst`` - Update parameter table to"},{"line_number":208,"context_line":"  show new names as primary and old names as deprecated"},{"line_number":209,"context_line":"* User guides - Update all examples to use new field names"},{"line_number":210,"context_line":"* API documentation - Add notes about the deprecation"},{"line_number":211,"context_line":"* Release notes - Document the change and migration timeline"},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"Performance Impact"},{"line_number":214,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"02218bbb_842302f3","line":211,"range":{"start_line":203,"start_character":0,"end_line":211,"end_character":60},"in_reply_to":"b3befc63_b5b87686","updated":"2025-12-16 16:41:49.000000000","message":"moved it there","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":false,"context_lines":[{"line_number":272,"context_line":"This change has no dependencies. It is self-contained within the"},{"line_number":273,"context_line":"Watcher project, and can be carried out in parallel to any other Watcher spec."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Testing"},{"line_number":276,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"**Unit Tests**"}],"source_content_type":"text/x-rst","patch_set":5,"id":"df7ff392_76f28f33","line":275,"in_reply_to":"1ac19f74_c82f8ba3","updated":"2025-12-15 13:34:25.000000000","message":"that is not in the scope of tempet to test.\n\ntempest should test the new paramters and old parmater but \n\ndatabase migration verification is not in scope","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"914385515694bf6dfb322db1ec7f82456688dd75","unresolved":true,"context_lines":[{"line_number":304,"context_line":""},{"line_number":305,"context_line":"**Tempest Tests**"},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"* The Zone migration strategy tests will be updated to use the new parameters"},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"Documentation Impact"},{"line_number":310,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a077ca54_0d24955f","line":307,"updated":"2025-12-15 13:34:25.000000000","message":"we should we need to continue to test with the old parmater and shoudl add some test that use the new ones if the cloud supports them.","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"a6aebf101b21224f365f7337f03b9d27aae54844","unresolved":true,"context_lines":[{"line_number":304,"context_line":""},{"line_number":305,"context_line":"**Tempest Tests**"},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"* The Zone migration strategy tests will be updated to use the new parameters"},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"Documentation Impact"},{"line_number":310,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fd84564c_b86a37e1","line":307,"in_reply_to":"a077ca54_0d24955f","updated":"2025-12-15 14:43:01.000000000","message":"ack, I\u0027ve changed the text to continue using the old names in the existing tempest tests and add a new test with the new tests","commit_id":"ab943c1d635f43948c8b086fc5bde1d074f6f42d"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"03ca1c60f06ac8e3f694f27c6a96d550e3439d56","unresolved":true,"context_lines":[{"line_number":118,"context_line":"Instead of renaming the parameters, we could improve the documentation to"},{"line_number":119,"context_line":"clarify:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* That \"pool\" parameters refer to full storage host identifiers"},{"line_number":122,"context_line":"* That \"parallel\" parameters are actually action rate limits"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"This would require no code changes and no upgrade implications, but it would"},{"line_number":125,"context_line":"not address the fundamental naming confusion both in the parameter names and"}],"source_content_type":"text/x-rst","patch_set":8,"id":"19488770_6ca917dc","line":122,"range":{"start_line":121,"start_character":0,"end_line":122,"end_character":60},"updated":"2025-12-17 19:34:39.000000000","message":"Wasn\u0027t already made?","commit_id":"5410906aef56cc7e068e4a83e07fdf763e1ea2c2"}]}