)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"9cd549468d34b1f7c14c0ea0bec90df81a875ab8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"c5cdd68a_da7b8be4","updated":"2026-06-23 09:09:50.000000000","message":"This helps to reduce execution time for tempest tests. I\u0027m afraid will not be a big drop, but makes sense and any optimization is appreciated","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"cbbb41d0b48a3fc93ef236d6a4fde178e8e60f8c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"31f24589_317d34cd","updated":"2026-06-23 06:54:50.000000000","message":"check experimental","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"38d50f301854a4f80dd6f0608b138e98f8c3a5b6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"7e8fdbce_60f248b1","updated":"2026-06-23 06:50:06.000000000","message":"check-experimental","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"}],"watcher_tempest_plugin/config.py":[{"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":"c309114383e74d31157e886646ab374d13b5249f","unresolved":false,"context_lines":[{"line_number":136,"context_line":"             \"resources (audits, action plans, compute nodes) to reach \""},{"line_number":137,"context_line":"             \"an expected state.\""},{"line_number":138,"context_line":"    ),"},{"line_number":139,"context_line":"    cfg.IntOpt("},{"line_number":140,"context_line":"        \"resource_timeout\","},{"line_number":141,"context_line":"        default\u003d300,"},{"line_number":142,"context_line":"        help\u003d\"Maximum time in seconds to wait for Watcher resources \""}],"source_content_type":"text/x-python","patch_set":2,"id":"b42b133f_80ef4a9a","line":139,"updated":"2026-06-22 19:20:38.000000000","message":"resource_timeout is an IntOpt while resource_check_interval is a FloatOpt; the division at line 372 yields a float that math.ceil absorbs, but the type asymmetry is unnecessary and resource_timeout as a duration could reasonably be fractional too.\n\n**Severity**: SUGGESTION | **Confidence**: 0.7\n\n**Benefit**: Consistent FloatOpt typing for all duration/interval options avoids surprising integer truncation elsewhere the value is reused and matches the model_check_interval/resource_check_interval precedent.\n\n**Recommendation**:\nConsider making resource_timeout and model_timeout FloatOpt for symmetry with the interval options, or document why the timeout must be integer-valued.","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"}],"watcher_tempest_plugin/tests/api/admin/test_audit.py":[{"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":"d5da15abfaa2bffc7fa56bad28e3394060b3d55a","unresolved":false,"context_lines":[{"line_number":149,"context_line":""},{"line_number":150,"context_line":"        _, body \u003d self.create_audit(**audit_params)"},{"line_number":151,"context_line":"        audit_uuid \u003d body[\u0027uuid\u0027]"},{"line_number":152,"context_line":"        test_utils.call_until_true("},{"line_number":153,"context_line":"            func\u003dfunctools.partial("},{"line_number":154,"context_line":"                self.is_audit_ongoing, audit_uuid),"},{"line_number":155,"context_line":"            duration\u003dCONF.optimize.resource_timeout,"}],"source_content_type":"text/x-python","patch_set":1,"id":"521132a7_da796f6f","line":152,"updated":"2026-06-22 16:05:41.000000000","message":"Best-effort wait sites in test_audit.py (test_update_audit, test_delete_audit) previously used short durations (5s, 10s) for transient conditions, now use resource_timeout (300s default). Return value is discarded (no assert), so tests wait the full 300s if the condition is never met.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Best-effort waits for transient states (audit ONGOING, audit IDLE, audit deleted) now block up to 300s if the state transition is missed, significantly slowing test execution. The previous 5-10s durations were intentional for quick verification of fast transitions.\n\n**Suggestion**:\nFor transient-state waits where missing the window is acceptable, keep a short explicit duration rather than the general resource_timeout. Consider a short-duration config option or pass an explicit small duration for positive-condition checks on fast transitions.","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"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":"c309114383e74d31157e886646ab374d13b5249f","unresolved":false,"context_lines":[{"line_number":152,"context_line":"        test_utils.call_until_true("},{"line_number":153,"context_line":"            func\u003dfunctools.partial("},{"line_number":154,"context_line":"                self.is_audit_ongoing, audit_uuid),"},{"line_number":155,"context_line":"            duration\u003dCONF.optimize.resource_timeout,"},{"line_number":156,"context_line":"            sleep_for\u003dCONF.optimize.resource_check_interval"},{"line_number":157,"context_line":"        )"},{"line_number":158,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"9817b972_c84954c4","line":155,"updated":"2026-06-22 19:20:38.000000000","message":"Several API tests previously used short durations deliberately scoped to the operation: is_audit_ongoing duration\u003d10, is_audit_idle duration\u003d10, is_audit_deleted duration\u003d5. All are now resource_timeout\u003d300, a 30-60x increase in the failure-path wall time of those tests.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: On a regression where the condition never becomes true, these smoke-tagged tests will now burn up to 300s each (vs 5-10s) before the subsequent assertion fires, noticeably slowing the gate and delaying failure signal.\n\n**Suggestion**:\nKeep the operation-specific short durations as inline literals or add a finer-grained option (e.g. quick_state_timeout) for these fast-state checks. If a single value is desired, a default smaller than 300 (e.g. 60) better balances the API-test cases.","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"}],"watcher_tempest_plugin/tests/scenario/base.py":[{"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":"d5da15abfaa2bffc7fa56bad28e3394060b3d55a","unresolved":false,"context_lines":[{"line_number":223,"context_line":"                LOG.exception(exc)"},{"line_number":224,"context_line":"                return False"},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"        assert test_utils.call_until_true("},{"line_number":227,"context_line":"            func\u003d_are_compute_nodes_setup,"},{"line_number":228,"context_line":"            duration\u003dCONF.optimize.resource_timeout,"},{"line_number":229,"context_line":"            sleep_for\u003dCONF.optimize.resource_check_interval"}],"source_content_type":"text/x-python","patch_set":1,"id":"d489afa8_51ed775f","line":226,"updated":"2026-06-22 16:05:41.000000000","message":"Call sites previously had duration\u003d600 (10 min) now use resource_timeout default 300 (5 min), halving max wait. Affected: scenario/base.py compute node setup, gnocchi measures, action plan/audit waits; client_functional audit creation; test_continuous_audit.py.\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: Tests that could take up to 600s for slow operations (compute node setup, gnocchi measures, action plan execution) now time out at 300s, which may cause intermittent failures in heavily loaded or slow CI environments where operations legitimately take longer.\n\n**Priority**: Before merge\n**Why This Matters**: The commit states default behavior should match previous values, but duration\u003d600 call sites are now capped at 300s. This is a behavioral regression risk. Operators relying on the implicit 600s ceiling will see new timeout failures unless they override resource_timeout.\n\n**Recommendation**:\nEither set resource_timeout default to 600 to preserve the longest previous duration, or introduce separate timeout options for genuinely slow operations (compute node setup, gnocchi measures) vs fast resource state checks. At minimum, document that the default max-wait for previously-600s call sites is reduced to 300s.","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"bd9ef1b06b153bfd925931a66430e5bfb82dca14","unresolved":true,"context_lines":[{"line_number":249,"context_line":"                rollback_func(svr_id, status\u003dstatus)"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"    @classmethod"},{"line_number":252,"context_line":"    def wait_for(cls, condition, timeout\u003d30):"},{"line_number":253,"context_line":"        start_time \u003d time.time()"},{"line_number":254,"context_line":"        while time.time() - start_time \u003c timeout:"},{"line_number":255,"context_line":"            if condition():"}],"source_content_type":"text/x-python","patch_set":1,"id":"b55814ac_c26009ef","line":252,"range":{"start_line":252,"start_character":33,"end_line":252,"end_character":44},"updated":"2026-06-22 15:48:19.000000000","message":"Missed this","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"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":"d5da15abfaa2bffc7fa56bad28e3394060b3d55a","unresolved":false,"context_lines":[{"line_number":249,"context_line":"                rollback_func(svr_id, status\u003dstatus)"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"    @classmethod"},{"line_number":252,"context_line":"    def wait_for(cls, condition, timeout\u003d30):"},{"line_number":253,"context_line":"        start_time \u003d time.time()"},{"line_number":254,"context_line":"        while time.time() - start_time \u003c timeout:"},{"line_number":255,"context_line":"            if condition():"}],"source_content_type":"text/x-python","patch_set":1,"id":"69033778_988babc4","line":252,"updated":"2026-06-22 16:05:41.000000000","message":"The wait_for() classmethod still has a hardcoded default timeout\u003d30 parameter, while the time.sleep() inside it was changed to use resource_check_interval. This creates an inconsistency: the interval is configurable but the timeout is not.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: The wait_for() helper is used for condition waits in scenario tests. Making only the sleep interval configurable but not the timeout is an incomplete refactor that may confuse operators expecting consistent configurability.\n\n**Suggestion**:\nEither make the wait_for() timeout configurable (e.g., default to resource_timeout), or add a brief comment explaining why this specific helper retains a fixed 30s timeout if intentional.","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"2eea62ca86c5f7b244ba47c2c79a5106282d1d55","unresolved":false,"context_lines":[{"line_number":249,"context_line":"                rollback_func(svr_id, status\u003dstatus)"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"    @classmethod"},{"line_number":252,"context_line":"    def wait_for(cls, condition, timeout\u003d30):"},{"line_number":253,"context_line":"        start_time \u003d time.time()"},{"line_number":254,"context_line":"        while time.time() - start_time \u003c timeout:"},{"line_number":255,"context_line":"            if condition():"}],"source_content_type":"text/x-python","patch_set":1,"id":"f3e8669a_991cc1e9","line":252,"range":{"start_line":252,"start_character":33,"end_line":252,"end_character":44},"in_reply_to":"5ae27a72_0ad4d609","updated":"2026-06-22 19:10:03.000000000","message":"Done","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"59086396a2879998087f57830459a2734b43b210","unresolved":true,"context_lines":[{"line_number":249,"context_line":"                rollback_func(svr_id, status\u003dstatus)"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"    @classmethod"},{"line_number":252,"context_line":"    def wait_for(cls, condition, timeout\u003d30):"},{"line_number":253,"context_line":"        start_time \u003d time.time()"},{"line_number":254,"context_line":"        while time.time() - start_time \u003c timeout:"},{"line_number":255,"context_line":"            if condition():"}],"source_content_type":"text/x-python","patch_set":1,"id":"5ae27a72_0ad4d609","line":252,"range":{"start_line":252,"start_character":33,"end_line":252,"end_character":44},"in_reply_to":"b55814ac_c26009ef","updated":"2026-06-22 18:07:08.000000000","message":"right we should default Timeout to  None i guess\nand then do \ntimeout \u003d timeout or CONF.optimize.resource_check_interval","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"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":"d5da15abfaa2bffc7fa56bad28e3394060b3d55a","unresolved":false,"context_lines":[{"line_number":367,"context_line":"            # We need node status is enabled, so we check the node"},{"line_number":368,"context_line":"            # trait and delay if it is not the correct status."},{"line_number":369,"context_line":"            node_trait \u003d os_traits.COMPUTE_STATUS_DISABLED"},{"line_number":370,"context_line":"            retry \u003d math.ceil("},{"line_number":371,"context_line":"                CONF.optimize.resource_timeout"},{"line_number":372,"context_line":"                / CONF.optimize.resource_check_interval)"},{"line_number":373,"context_line":"            trait_status \u003d True"}],"source_content_type":"text/x-python","patch_set":1,"id":"dc502212_4413d37b","line":370,"updated":"2026-06-22 16:05:41.000000000","message":"Trait-removal retry loop polling frequency changed from 30s to 1s (default), a 30x increase. Previously: 20 retries sleeping 30s (10 min max). Now: 300 retries (ceil(300/1.0)) sleeping 1.0s. Total wall-clock similar, but 300 API polls vs 20 increases placement/nova API load.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: 300 polling iterations against placement/nova APIs per compute node where there were 20 before. In multi-node scenario tests this multiplies further, increasing API load and risk of rate-limiting or transient failures.\n\n**Priority**: Before merge\n**Why This Matters**: The original 30s interval was deliberate because the Nova update_available_resource periodic task runs on a ~60s cycle; polling every 1s does not help the trait clear faster and is wasteful. This loop needs a dedicated longer interval.\n\n**Recommendation**:\nIntroduce a separate config option (e.g., trait_check_interval with default 30) for this retry loop, or retain the original 30s sleep since the Nova periodic task cadence is unchanged. The 1s resource_check_interval is inappropriate for a periodic-task-driven condition.","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"59086396a2879998087f57830459a2734b43b210","unresolved":true,"context_lines":[{"line_number":367,"context_line":"            # We need node status is enabled, so we check the node"},{"line_number":368,"context_line":"            # trait and delay if it is not the correct status."},{"line_number":369,"context_line":"            node_trait \u003d os_traits.COMPUTE_STATUS_DISABLED"},{"line_number":370,"context_line":"            retry \u003d math.ceil("},{"line_number":371,"context_line":"                CONF.optimize.resource_timeout"},{"line_number":372,"context_line":"                / CONF.optimize.resource_check_interval)"},{"line_number":373,"context_line":"            trait_status \u003d True"}],"source_content_type":"text/x-python","patch_set":1,"id":"b6d781e3_54ad0253","line":370,"in_reply_to":"dc502212_4413d37b","updated":"2026-06-22 18:07:08.000000000","message":"we could but not it shoudl use the resocue timeout it is just an api request to placement in this case.","commit_id":"66069e3a33e1b84f2a5f0e35648ee1bd5dfab130"},{"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":"c309114383e74d31157e886646ab374d13b5249f","unresolved":false,"context_lines":[{"line_number":251,"context_line":"    @classmethod"},{"line_number":252,"context_line":"    def wait_for(cls, condition, timeout\u003dNone):"},{"line_number":253,"context_line":"        start_time \u003d time.time()"},{"line_number":254,"context_line":"        deadline \u003d timeout or CONF.optimize.resource_timeout"},{"line_number":255,"context_line":"        while time.time() - start_time \u003c deadline:"},{"line_number":256,"context_line":"            if condition():"},{"line_number":257,"context_line":"                break"}],"source_content_type":"text/x-python","patch_set":2,"id":"c454bece_c5288fab","line":254,"updated":"2026-06-22 19:20:38.000000000","message":"wait_for() now uses \u0027deadline \u003d timeout or CONF.optimize.resource_timeout\u0027. The \u0027or\u0027 idiom treats an explicitly passed timeout\u003d0 (or 0.0) as falsy and silently substitutes the config default, contrary to caller intent.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Any caller passing timeout\u003d0 expecting an immediate single-pass check (or no wait) instead gets a ~300s loop. The same \u0027timeout or CONF...\u0027 pattern repeats in wait_for_instances_in_model, wait_for_instances_attributes_in_model, and wait_delete_instances_from_model.\n\n**Suggestion**:\nUse \u0027deadline \u003d timeout if timeout is not None else CONF.optimize.resource_timeout\u0027 so only an unset (None) timeout falls back to config, preserving an explicit 0. Apply the same fix to the three model-wait helpers (lines 1100, 1139, 1171).","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"},{"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":"c309114383e74d31157e886646ab374d13b5249f","unresolved":false,"context_lines":[{"line_number":368,"context_line":"            # We need node status is enabled, so we check the node"},{"line_number":369,"context_line":"            # trait and delay if it is not the correct status."},{"line_number":370,"context_line":"            node_trait \u003d os_traits.COMPUTE_STATUS_DISABLED"},{"line_number":371,"context_line":"            retry \u003d math.ceil("},{"line_number":372,"context_line":"                CONF.optimize.resource_timeout"},{"line_number":373,"context_line":"                / CONF.optimize.resource_check_interval)"},{"line_number":374,"context_line":"            trait_status \u003d True"}],"source_content_type":"text/x-python","patch_set":2,"id":"3e0fa636_0a409a89","line":371,"updated":"2026-06-22 19:20:38.000000000","message":"Trait-removal retry loop changed materially. Original: retry\u003d20, sleep(30) -\u003e ~600s max over 20 placement checks. New: math.ceil(300/1.0)\u003d300 retries, sleep(1.0) -\u003e ~300s max over 300 check_node_trait calls. Max wait halved, API call frequency up 15x.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: Placement/nova conflict resolution window is cut from ~10 min to ~5 min while making 15x more API calls, increasing flakiness risk on slow CI and load on the placement service.\n\n**Priority**: Before merge\n**Why This Matters**: This loop waits for Nova\u0027s update_available_resource periodic task to clear a COMPUTE_STATUS_DISABLED trait. The original 600s window existed because that periodic can take minutes; 300s may be too short, and 300 tight polls add avoidable placement load.\n\n**Recommendation**:\nIntroduce a dedicated option (e.g. trait_removal_timeout, default 600) and a separate trait_removal_interval (e.g. 30) so the retry count is derived from matching values, preserving both the ~600s window and the original poll cadence. Re-add the \u0027max delay time\u0027 comment with the new values.","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"},{"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":"c309114383e74d31157e886646ab374d13b5249f","unresolved":false,"context_lines":[{"line_number":1116,"context_line":""},{"line_number":1117,"context_line":"        # Check all instances are in the model and model is not empty"},{"line_number":1118,"context_line":"        while (not set(instance_pairs) \u003c\u003d set(model_pairs) or not model_pairs):"},{"line_number":1119,"context_line":"            time.sleep(CONF.optimize.model_check_interval)"},{"line_number":1120,"context_line":"            if time.time() \u003e\u003d timeout_end:"},{"line_number":1121,"context_line":"                raise Exception(\"Instances are not mapped to compute model.\")"},{"line_number":1122,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"e34ba913_d91bbc67","line":1119,"updated":"2026-06-22 19:20:38.000000000","message":"Model-wait helpers now poll every model_check_interval (default 1.0s) instead of the original hardcoded 15s, a 15x increase in list_data_models API calls per wait. With timeout\u003d300 the loops now issue up to ~300 model-fetch HTTP requests instead of ~20.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: Each poll issues a GET to the Watcher compute data-model endpoint; a 15x call multiplier across every scenario test substantially increases load on watcher-decision-engine and the DB, and slows the suite via request overhead.\n\n**Priority**: Before merge\n**Why This Matters**: The Watcher compute model collector runs on its own periodic; the original 15s interval was chosen to align roughly with that cadence. Polling at 1.0s does not make the model appear faster and mainly adds wasted requests.\n\n**Recommendation**:\nSet model_check_interval default to 15.0 (matching prior behaviour) rather than 1.0, or document clearly that the default intentionally trades request volume for responsiveness. The same applies to the sibling sleeps at lines 1158 and 1182.","commit_id":"5ef3d55f37e765e7a8068381b7becccb33757d02"}]}