)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"27cb4a53918920f0acb6203dc5ff105d9aadb1a4","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     815ed72b (Merge \"Add 2027.1 spec structure\")"},{"line_number":2,"context_line":"Author:     Douglas Viroel \u003cviroel@gmail.com\u003e"},{"line_number":3,"context_line":"AuthorDate: 2026-06-24 15:28:05 -0300"},{"line_number":4,"context_line":"Commit:     Douglas Viroel \u003cviroel@gmail.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"0971cca4_5ff60141","line":1,"updated":"2026-10-08 20:01:26.000000000","message":"The change message reads \u0027The design is now splitted in 2 phases\u0027. \u0027Splitted\u0027 is not a valid English form of \u0027split\u0027, and \u0027split in 2 phases\u0027 should read \u0027split into 2 phases\u0027. There is also a double space in \u0027Filter Manager  that centralize\u0027. The meaning stays clear, but this text becomes permanent change history on the merged commit.\n\n**Severity**: SUGGESTION | **Confidence**: 0.95\n\n**Impact**: Permanent git history carries the misspelling; it slightly reduces the quality of the change record but does not obscure intent.\n\n**Recommendation**:\nWhen next amending the commit, update the sentence to \u0027The design is now split into 2 phases\u0027 and remove the double space in \u0027Filter Manager  that\u0027.","commit_id":"23fcbdb155f55662ba83a7ee01fc4a9cec4d9b38"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"b4431ef7431803edff99a8067696b51694d550b6","unresolved":true,"context_lines":[{"line_number":1,"context_line":"Parent:     815ed72b (Merge \"Add 2027.1 spec structure\")"},{"line_number":2,"context_line":"Author:     Douglas Viroel \u003cviroel@gmail.com\u003e"},{"line_number":3,"context_line":"AuthorDate: 2026-06-24 15:28:05 -0300"},{"line_number":4,"context_line":"Commit:     Douglas Viroel \u003cviroel@gmail.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"eb7ab860_da89eeb4","line":1,"in_reply_to":"0971cca4_5ff60141","updated":"2026-10-08 20:10:31.000000000","message":"is what happens when I don\u0027t use a model to write some text for me.","commit_id":"23fcbdb155f55662ba83a7ee01fc4a9cec4d9b38"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"54da4135_3661b4a3","updated":"2026-10-08 18:17:54.000000000","message":"Thanks for the review Alfred, and sorry for taking so long to answer your comments.\nI plan to update the spec for 2027.1 and also refactor it.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e8d85bfe_80ec6ea9","updated":"2026-06-25 09:26:13.000000000","message":"Thanks for this spec! some comments inline.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"}],"specs/2026.2/approved/migration-eligibility-filters.rst":[{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":43,"context_line":""},{"line_number":44,"context_line":"* Instances that belong to a server group are not identified or excluded."},{"line_number":45,"context_line":"  Migrating such instances without accounting for server group placement rules"},{"line_number":46,"context_line":"  can silently break operator-defined affinity or anti-affinity policies."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Use Cases"},{"line_number":49,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"195f843d_bfa3a972","line":46,"updated":"2026-06-25 09:26:13.000000000","message":"Also, strategies are also inconsistent checking resources allocations in hosts to fit the instances. May this filter mechanism be appropriate for this issue? if so, it may be worthy to include it in scope.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":43,"context_line":""},{"line_number":44,"context_line":"* Instances that belong to a server group are not identified or excluded."},{"line_number":45,"context_line":"  Migrating such instances without accounting for server group placement rules"},{"line_number":46,"context_line":"  can silently break operator-defined affinity or anti-affinity policies."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Use Cases"},{"line_number":49,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"706f890f_125903fc","line":46,"in_reply_to":"195f843d_bfa3a972","updated":"2026-10-08 18:17:54.000000000","message":"I think that yes, we can initially do a refactoring to make this destination node checks and allocation checking common for all strategies. The corner case are strategies that simulate migration + check thresholds (for capacity), in this case we can think on a future improvement. (this is also different from usage thresholds)","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":63,"context_line":""},{"line_number":64,"context_line":"1. Add two methods to ``BaseStrategy``:"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"   * ``filter_instances_for_migration`` — returns the subset of instances on a"},{"line_number":67,"context_line":"     source node that are eligible for migration, applying Nova migration"},{"line_number":68,"context_line":"     constraints derivable from instance attributes already tracked in the CDM."},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"db928d04_8a4936e8","line":66,"range":{"start_line":66,"start_character":7,"end_line":66,"end_character":37},"updated":"2026-06-25 09:26:13.000000000","message":"In the past we have also discussed about having mechanism to exclude instances from migration based on Nova metadata (tags, labels, hints, or other metadata forms, i.e. optimize:no-migrate). I understand this may be also implemented via this filters. I\u0027m not saying to include in the scope of this spec, just to understand the kind of use cases where this mechanism may be used in future.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":63,"context_line":""},{"line_number":64,"context_line":"1. Add two methods to ``BaseStrategy``:"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"   * ``filter_instances_for_migration`` — returns the subset of instances on a"},{"line_number":67,"context_line":"     source node that are eligible for migration, applying Nova migration"},{"line_number":68,"context_line":"     constraints derivable from instance attributes already tracked in the CDM."},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"a6ce0e60_8a4b75e4","line":66,"updated":"2026-06-24 18:48:20.000000000","message":"Line exceeds the 79-character limit required by the spec template. This line is exactly 80 characters, including the em dash. The template states \u0027Please wrap text at 79 columns.\u0027\n\n**Severity**: WARNING | **Confidence**: 1.0\n\n**Impact**: Violates the explicit RST wrapping rule in the 2026.2 spec template. Inconsistent line lengths across the document.\n\n**Suggestion**:\nWrap the line to fit within 79 characters, e.g., break after \u0027instances on a\u0027 or rephrase to shorten.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":63,"context_line":""},{"line_number":64,"context_line":"1. Add two methods to ``BaseStrategy``:"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"   * ``filter_instances_for_migration`` — returns the subset of instances on a"},{"line_number":67,"context_line":"     source node that are eligible for migration, applying Nova migration"},{"line_number":68,"context_line":"     constraints derivable from instance attributes already tracked in the CDM."},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"4fa94f8f_975629ca","line":66,"range":{"start_line":66,"start_character":7,"end_line":66,"end_character":37},"in_reply_to":"db928d04_8a4936e8","updated":"2026-10-08 18:17:54.000000000","message":"It is a important feature for users, not only to filter invalid migrations, but also exclude specific group of instances from being migrated. I think that this filtering based on extra-spec or metadata fits better on improving audit scope, while the proposed filters here are more focused on placement constraints and capacity.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":67,"context_line":"     source node that are eligible for migration, applying Nova migration"},{"line_number":68,"context_line":"     constraints derivable from instance attributes already tracked in the CDM."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"   * ``filter_destination_nodes`` — returns the subset of candidate nodes that"},{"line_number":71,"context_line":"     are valid migration destinations for a specific instance, checking node"},{"line_number":72,"context_line":"     administrative state and per-instance scheduler hint constraints."},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ac34e201_608cfb27","line":70,"updated":"2026-06-24 18:48:20.000000000","message":"Line exceeds the 79-character limit required by the spec template. This line is exactly 80 characters, including the em dash.\n\n**Severity**: WARNING | **Confidence**: 1.0\n\n**Impact**: Violates the explicit RST wrapping rule in the 2026.2 spec template.\n\n**Suggestion**:\nWrap the line to fit within 79 characters, e.g., break after \u0027candidate nodes that\u0027 or rephrase.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":74,"context_line":"2. Refactor in-scope strategies to call these base methods instead of"},{"line_number":75,"context_line":"   duplicating the same checks inline."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Resource capacity checks are intentionally excluded from both methods. Each"},{"line_number":78,"context_line":"strategy accounts for resources differently (for example, ``uniform_airflow``"},{"line_number":79,"context_line":"tracks running usage across multiple migrations within a single execution"},{"line_number":80,"context_line":"pass). Strategies retain full control over resource-based ranking and"},{"line_number":81,"context_line":"selection."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"``filter_instances_for_migration`` Method"},{"line_number":84,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa2d8a35_d19c16fd","line":81,"range":{"start_line":77,"start_character":0,"end_line":81,"end_character":10},"updated":"2026-06-25 09:26:13.000000000","message":"I have doubts about this. Each strategy can has its way of priorizing or calculating the resources for candidates but checking if the proposed hosts have available resource allocations to accept a VM should be consistent accross all the strategies, otherwise VMs will fail to migrate similarly to the rest of nova constraints you mention. IMO the filter_destination_nodes should check suitability based on free allocations too.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":74,"context_line":"2. Refactor in-scope strategies to call these base methods instead of"},{"line_number":75,"context_line":"   duplicating the same checks inline."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Resource capacity checks are intentionally excluded from both methods. Each"},{"line_number":78,"context_line":"strategy accounts for resources differently (for example, ``uniform_airflow``"},{"line_number":79,"context_line":"tracks running usage across multiple migrations within a single execution"},{"line_number":80,"context_line":"pass). Strategies retain full control over resource-based ranking and"},{"line_number":81,"context_line":"selection."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"``filter_instances_for_migration`` Method"},{"line_number":84,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"27ead846_25159b27","line":81,"range":{"start_line":77,"start_character":0,"end_line":81,"end_character":10},"in_reply_to":"fa2d8a35_d19c16fd","updated":"2026-10-08 18:17:54.000000000","message":"Yeah, agree, every strategy don\u0027t need to implement allocation checks since it should be the same for all. Metrics/usage is a different topic here, since each strategy can have different analysis of metric data.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":97,"context_line":"        source_node to destination_node are also excluded."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"        :param source_node: ComputeNode to migrate from"},{"line_number":100,"context_line":"        :param destination_node: optional target ComputeNode"},{"line_number":101,"context_line":"        :param acceptable_states: list of InstanceState string values;"},{"line_number":102,"context_line":"            when not provided, defaults to [ACTIVE, PAUSED] for live"},{"line_number":103,"context_line":"            migration or [STOPPED] for cold migration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c4e4fea2_01ec28fb","line":100,"range":{"start_line":100,"start_character":15,"end_line":100,"end_character":31},"updated":"2026-06-25 09:26:13.000000000","message":"when calling filter_instances_for_migration with a destination_node, i understand it validates if destination is valid for each individual instance in current situation, it will not validate if the migration would be valid assuming that previous instances have been migrated, am i correct?","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":97,"context_line":"        source_node to destination_node are also excluded."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"        :param source_node: ComputeNode to migrate from"},{"line_number":100,"context_line":"        :param destination_node: optional target ComputeNode"},{"line_number":101,"context_line":"        :param acceptable_states: list of InstanceState string values;"},{"line_number":102,"context_line":"            when not provided, defaults to [ACTIVE, PAUSED] for live"},{"line_number":103,"context_line":"            migration or [STOPPED] for cold migration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9ab2f364_990a7473","line":100,"range":{"start_line":100,"start_character":15,"end_line":100,"end_character":31},"in_reply_to":"c4e4fea2_01ec28fb","updated":"2026-10-08 18:17:54.000000000","message":"It will be based on the current strategies copy of the model. If we also refactor strategies to always use Model migration method, it will update the allocation info in the model, so the next iteration would yes consider that.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":101,"context_line":"        :param acceptable_states: list of InstanceState string values;"},{"line_number":102,"context_line":"            when not provided, defaults to [ACTIVE, PAUSED] for live"},{"line_number":103,"context_line":"            migration or [STOPPED] for cold migration"},{"line_number":104,"context_line":"        :param migration_type: \u0027live\u0027 (default) or \u0027cold\u0027; controls which"},{"line_number":105,"context_line":"            flavor-based constraints are applied"},{"line_number":106,"context_line":"        :returns: list of Instance"},{"line_number":107,"context_line":"        \"\"\""},{"line_number":108,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a490f07_5d806f56","line":105,"range":{"start_line":104,"start_character":1,"end_line":105,"end_character":48},"updated":"2026-06-25 09:26:13.000000000","message":"Are there cases where an instance can not be live-migrated because its config (whatever the destination node is, just because it\u0027s characteristics)? If so (I\u0027m not sure), it may be good to have another method is_live_migratable(instance)? so that a strategy knows when should only do cold migrations and not check for live migrations in all the destinations.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":101,"context_line":"        :param acceptable_states: list of InstanceState string values;"},{"line_number":102,"context_line":"            when not provided, defaults to [ACTIVE, PAUSED] for live"},{"line_number":103,"context_line":"            migration or [STOPPED] for cold migration"},{"line_number":104,"context_line":"        :param migration_type: \u0027live\u0027 (default) or \u0027cold\u0027; controls which"},{"line_number":105,"context_line":"            flavor-based constraints are applied"},{"line_number":106,"context_line":"        :returns: list of Instance"},{"line_number":107,"context_line":"        \"\"\""},{"line_number":108,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ac2020f_cd2095e4","line":105,"range":{"start_line":104,"start_character":1,"end_line":105,"end_character":48},"in_reply_to":"5a490f07_5d806f56","updated":"2026-10-08 18:17:54.000000000","message":"I am removing this detail for now, and considering all instances that can be live/cold migrated. Strategies can then decide to migrate or not, and create the proper migrate action. Methods could internally do some checks based on instance state I think.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":115,"context_line":"* ``instance.state`` not in ``acceptable_states`` — wrong VM state. When not"},{"line_number":116,"context_line":"  explicitly provided, ``acceptable_states`` defaults to ``[ACTIVE, PAUSED]``"},{"line_number":117,"context_line":"  for live migration or ``[STOPPED]`` for cold migration."},{"line_number":118,"context_line":"* ``instance.locked`` is ``True`` — Nova rejects migration of locked instances"},{"line_number":119,"context_line":"  for non-admin callers."},{"line_number":120,"context_line":"* ``instance.scheduler_hints.get(\u0027group\u0027)`` is non-empty — the instance"},{"line_number":121,"context_line":"  belongs to a server group. Server group migrations are not supported in this"}],"source_content_type":"text/x-rst","patch_set":1,"id":"adbf7225_dbaef67e","line":118,"updated":"2026-06-24 18:48:20.000000000","message":"Line exceeds the 79-character limit required by the spec template. This line is exactly 80 characters, including the em dash and RST inline markup.\n\n**Severity**: WARNING | **Confidence**: 1.0\n\n**Impact**: Violates the explicit RST wrapping rule in the 2026.2 spec template.\n\n**Suggestion**:\nWrap the line to fit within 79 characters, e.g., move \u0027for non-admin callers.\u0027 to the next line or rephrase.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":121,"context_line":"  belongs to a server group. Server group migrations are not supported in this"},{"line_number":122,"context_line":"  version."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The method then applies category-based exclusions from ``flavor_extra_specs``."},{"line_number":125,"context_line":"The exact set of checks that apply to each migration type requires further"},{"line_number":126,"context_line":"investigation and will be refined during implementation; the ``migration_type``"},{"line_number":127,"context_line":"parameter is present in the signature to support that differentiation."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b1b22eb8_e0cc3232","line":124,"updated":"2026-06-24 18:48:20.000000000","message":"The spec does not describe what happens when flavor_extra_specs is missing, None, or malformed (not a dict, unexpected value types). The implementation should handle this gracefully to avoid runtime exceptions.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Benefit**: Explicitly documenting the expected input format and failure mode prevents implementation ambiguity and ensures the method degrades gracefully on incomplete CDM data.\n\n**Recommendation**:\nAdd a note stating that flavor_extra_specs defaults to an empty dict when absent, and that unknown or malformed values are treated as non-blocking (the instance is not excluded based on that key).","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":122,"context_line":"  version."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The method then applies category-based exclusions from ``flavor_extra_specs``."},{"line_number":125,"context_line":"The exact set of checks that apply to each migration type requires further"},{"line_number":126,"context_line":"investigation and will be refined during implementation; the ``migration_type``"},{"line_number":127,"context_line":"parameter is present in the signature to support that differentiation."},{"line_number":128,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a9757ee_8c192218","line":125,"updated":"2026-06-24 18:48:20.000000000","message":"The migration_type parameter is present in both method signatures but the spec explicitly defers defining which checks apply to each migration type, saying it \u0027requires further investigation and will be refined during implementation.\u0027\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Reviewers cannot evaluate whether the proposed filtering logic correctly differentiates live vs cold migration constraints. This is a core design question left unanswered in an approved spec.\n\n**Suggestion**:\nProvide at least a preliminary mapping of which checks differ between live and cold migration (e.g., PCI passthrough behavior, vTPM) before the spec is approved, even if fine-tuning happens during implementation.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"* ``hw:cpu_policy`` equals ``\u0027dedicated\u0027`` or ``\u0027mixed\u0027`` — instance uses CPU"},{"line_number":136,"context_line":"  pinning."},{"line_number":137,"context_line":"* Any key starting with ``hw:numa_`` — instance has an explicit NUMA topology."},{"line_number":138,"context_line":"* ``hw:mem_page_size`` is present and not ``\u0027small\u0027`` — instance uses huge"},{"line_number":139,"context_line":"  pages; specific page-size availability on the destination cannot be"},{"line_number":140,"context_line":"  guaranteed."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9e8427fc_3dbf435a","line":137,"updated":"2026-06-24 18:48:20.000000000","message":"Line exceeds the 79-character limit required by the spec template. This line is exactly 80 characters, including the em dash.\n\n**Severity**: WARNING | **Confidence**: 1.0\n\n**Impact**: Violates the explicit RST wrapping rule in the 2026.2 spec template.\n\n**Suggestion**:\nWrap the line to fit within 79 characters, e.g., break after \u0027NUMA topology.\u0027 on the next line or shorten the description.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":142,"context_line":"  incompatible with migration in most deployments."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"**PCI Passthrough / SR-IOV devices / VGPUs**"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* Any key starting with ``pci_passthrough:`` — PCI passthrough or direct-mode"},{"line_number":147,"context_line":"  SR-IOV; physical address binding prevents live migration. Cold migration"},{"line_number":148,"context_line":"  behaviour depends on device type and Nova configuration."}],"source_content_type":"text/x-rst","patch_set":1,"id":"aef910bb_88222428","line":145,"updated":"2026-06-25 09:26:13.000000000","message":"IIUC, for instances with pci passthrough or sr-iov devices, nova checks the available resources in the destination to attach to the requestin VM. The plan is to check that from available resources in placement to validate suitability for destination with cold-migration in these filters in watcher?","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":142,"context_line":"  incompatible with migration in most deployments."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"**PCI Passthrough / SR-IOV devices / VGPUs**"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* Any key starting with ``pci_passthrough:`` — PCI passthrough or direct-mode"},{"line_number":147,"context_line":"  SR-IOV; physical address binding prevents live migration. Cold migration"},{"line_number":148,"context_line":"  behaviour depends on device type and Nova configuration."}],"source_content_type":"text/x-rst","patch_set":1,"id":"867acd78_0559f35e","line":145,"in_reply_to":"aef910bb_88222428","updated":"2026-10-08 18:17:54.000000000","message":"IN future yes, but for now if a destination host needs to be selected, it will return []/False. In this case, we would need to let Nova Scheduler select a destination node, if the strategy permits.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* Any key starting with ``pci_passthrough:`` — PCI passthrough or direct-mode"},{"line_number":147,"context_line":"  SR-IOV; physical address binding prevents live migration. Cold migration"},{"line_number":148,"context_line":"  behaviour depends on device type and Nova configuration."},{"line_number":149,"context_line":"* Any key matching ``resources\\d*:SRIOV_NET_VF`` — SR-IOV virtual function"},{"line_number":150,"context_line":"  via resource group; same constraint as PCI passthrough."},{"line_number":151,"context_line":"* Any key matching ``resources\\d*:VGPU`` — virtual GPU; live migration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5545a237_cab8dcde","line":148,"updated":"2026-06-24 18:48:20.000000000","message":"Cold migration PCI passthrough behavior is described as dependent on \u0027device type and Nova configuration\u0027 without specifying which device types are affected or how Watcher will resolve the ambiguity.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Implementers and operators cannot predict whether cold migration will be proposed for PCI passthrough instances. The spec should clarify the conservative default (block) or reference Nova configuration keys.\n\n**Suggestion**:\nSpecify the default conservative behavior (block cold migration for all PCI passthrough devices) and note that device-specific exceptions may be added later based on Nova capabilities.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":162,"context_line":"  memory with CPU-bound keys."},{"line_number":163,"context_line":"* Any key matching ``trait\\d*:HW_CPU_X86_INTEL_TDX`` has value ``\u0027required\u0027``"},{"line_number":164,"context_line":"  — Intel TDX confidential VMs encrypt guest memory with CPU-specific keys."},{"line_number":165,"context_line":"* ``hw:cpu_mode`` equals ``\u0027host-passthrough\u0027`` — the instance was booted with"},{"line_number":166,"context_line":"  the exact host CPU model exposed to the guest; the destination must have an"},{"line_number":167,"context_line":"  identical CPU model, which Watcher cannot verify without CPU inventory data"},{"line_number":168,"context_line":"  in the CDM."}],"source_content_type":"text/x-rst","patch_set":1,"id":"f23db771_8969a80a","line":165,"updated":"2026-06-24 18:48:20.000000000","message":"Line exceeds the 79-character limit required by the spec template. This line is exactly 80 characters, including the em dash.\n\n**Severity**: WARNING | **Confidence**: 1.0\n\n**Impact**: Violates the explicit RST wrapping rule in the 2026.2 spec template.\n\n**Suggestion**:\nWrap the line to fit within 79 characters, e.g., break after \u0027booted with\u0027 or rephrase.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":166,"context_line":"  the exact host CPU model exposed to the guest; the destination must have an"},{"line_number":167,"context_line":"  identical CPU model, which Watcher cannot verify without CPU inventory data"},{"line_number":168,"context_line":"  in the CDM."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"**vTPM**"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"* The key ``hw:tpm_model`` is present — virtual TPM live migration is"}],"source_content_type":"text/x-rst","patch_set":1,"id":"682d5316_5b96f365","line":169,"updated":"2026-06-25 09:26:13.000000000","message":"You mentioned Hypervisor Version Filtering but didn\u0027t include hypervisor fields hypervisor_type and hypervisor_version which i understand is what it refers to.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":166,"context_line":"  the exact host CPU model exposed to the guest; the destination must have an"},{"line_number":167,"context_line":"  identical CPU model, which Watcher cannot verify without CPU inventory data"},{"line_number":168,"context_line":"  in the CDM."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"**vTPM**"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"* The key ``hw:tpm_model`` is present — virtual TPM live migration is"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2ac289f8_d76a5d06","line":169,"in_reply_to":"682d5316_5b96f365","updated":"2026-10-08 18:17:54.000000000","message":"Needs further investigation but yes, we could check that since would be an info available in the model. I will check that afterwards.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":169,"context_line":""},{"line_number":170,"context_line":"**vTPM**"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"* The key ``hw:tpm_model`` is present — virtual TPM live migration is"},{"line_number":173,"context_line":"  unsupported in most deployments. A Nova spec was approved for the 2025.1"},{"line_number":174,"context_line":"  Epoxy cycle; this is treated as a blocker until Watcher targets that release."},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c8991065_60924c4c","line":172,"range":{"start_line":172,"start_character":1,"end_line":172,"end_character":66},"updated":"2026-06-25 09:26:13.000000000","message":"This is the kind of use case i meant when proposing a method is_live_migratable(instance)","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":169,"context_line":""},{"line_number":170,"context_line":"**vTPM**"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"* The key ``hw:tpm_model`` is present — virtual TPM live migration is"},{"line_number":173,"context_line":"  unsupported in most deployments. A Nova spec was approved for the 2025.1"},{"line_number":174,"context_line":"  Epoxy cycle; this is treated as a blocker until Watcher targets that release."},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"6e1c22c9_46a6d38b","line":172,"range":{"start_line":172,"start_character":1,"end_line":172,"end_character":66},"in_reply_to":"c8991065_60924c4c","updated":"2026-10-08 18:17:54.000000000","message":"Lets see how it goes, but if the instance is ACTION and has ``hw:tpm_model``, it won\u0027t be suitable for migration.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":170,"context_line":"**vTPM**"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"* The key ``hw:tpm_model`` is present — virtual TPM live migration is"},{"line_number":173,"context_line":"  unsupported in most deployments. A Nova spec was approved for the 2025.1"},{"line_number":174,"context_line":"  Epoxy cycle; this is treated as a blocker until Watcher targets that release."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"For ``flavor_extra_specs`` keys that include a numeric resource group suffix"}],"source_content_type":"text/x-rst","patch_set":1,"id":"70f6353f_9d918ec7","line":173,"updated":"2026-06-24 18:48:20.000000000","message":"The vTPM section treats live migration as a blanket blocker, but acknowledges a Nova spec was approved for the 2025.1 Epoxy cycle. The spec lacks a clear policy for when the block can be lifted as deployments adopt the feature.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: The blanket block may become overly conservative as Nova gains vTPM live migration support. The spec does not describe a version-gating or capability-detection mechanism.\n\n**Suggestion**:\nAdd a sentence describing the intended policy: either version-gate based on the Nova API microversion, or state that the block will be revisited when Watcher targets a release that supports vTPM migration.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"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":"430888f07436fc473a50f59ae27c949a09e58fd3","unresolved":false,"context_lines":[{"line_number":175,"context_line":""},{"line_number":176,"context_line":"For ``flavor_extra_specs`` keys that include a numeric resource group suffix"},{"line_number":177,"context_line":"(e.g., ``resources1:SRIOV_NET_VF``, ``trait2:HW_CPU_X86_INTEL_TDX``), the"},{"line_number":178,"context_line":"suffix is stripped before matching: ``re.sub(r\u0027(\\D)\\d+:\u0027, r\u0027\\1:\u0027, key)``."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"When ``destination_node`` is given, the method additionally excludes instances"},{"line_number":181,"context_line":"for which ``filter_destination_nodes(instance, [destination_node], source_node,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"61b94a65_1815c240","line":178,"updated":"2026-06-24 18:48:20.000000000","message":"The regex re.sub(r\u0027(\\D)\\d+:\u0027, r\u0027\\1:\u0027, key) used to strip numeric resource group suffixes is correct for documented cases but has no explicitly documented expected input format or edge-case behavior.\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: Documenting the expected key format and edge cases (e.g., multi-digit suffixes, keys without colons) makes the regex easier to review and maintain.\n\n**Recommendation**:\nAdd a brief note specifying the expected input format (flavor extra spec keys following the \u0027namespace:value\u0027 or \u0027resource_group:namespace:value\u0027 convention) and confirm the regex handles multi-digit suffixes like resources10:.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":195,"context_line":"        constraint checks. Resource capacity checks are excluded."},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"        :param instance: Instance to be migrated"},{"line_number":198,"context_line":"        :param nodes: iterable of ComputeNode candidates"},{"line_number":199,"context_line":"        :param source_node: optional source node to exclude"},{"line_number":200,"context_line":"        :param migration_type: \u0027live\u0027 (default) or \u0027cold\u0027; reserved for"},{"line_number":201,"context_line":"            future use when destination checks diverge by migration type"}],"source_content_type":"text/x-rst","patch_set":1,"id":"56a34caf_c92e2754","line":198,"range":{"start_line":198,"start_character":0,"end_line":198,"end_character":2},"updated":"2026-06-25 09:26:13.000000000","message":"A though about scalability. In terms of scalability, it may be better for a strategy to validate if a candidate (or small list of) host is valid for a instance by setting nodes and iterate over the full list until finding a valid one that to run filter_destination_nodes with the entire list of the computes and then select a destination. While this implementation allows both, we should be careful when implementing strategies (i\u0027m not sure if adding a note in the spec may be appropiate).","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":195,"context_line":"        constraint checks. Resource capacity checks are excluded."},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"        :param instance: Instance to be migrated"},{"line_number":198,"context_line":"        :param nodes: iterable of ComputeNode candidates"},{"line_number":199,"context_line":"        :param source_node: optional source node to exclude"},{"line_number":200,"context_line":"        :param migration_type: \u0027live\u0027 (default) or \u0027cold\u0027; reserved for"},{"line_number":201,"context_line":"            future use when destination checks diverge by migration type"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e9cced9b_4ddb234e","line":198,"range":{"start_line":198,"start_character":0,"end_line":198,"end_character":2},"in_reply_to":"56a34caf_c92e2754","updated":"2026-10-08 18:17:54.000000000","message":"right, this is expected to be covered, mainly because there are strategies that sefine both source and destination hosts, so we would validate against [dest_host] only.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":196,"context_line":""},{"line_number":197,"context_line":"        :param instance: Instance to be migrated"},{"line_number":198,"context_line":"        :param nodes: iterable of ComputeNode candidates"},{"line_number":199,"context_line":"        :param source_node: optional source node to exclude"},{"line_number":200,"context_line":"        :param migration_type: \u0027live\u0027 (default) or \u0027cold\u0027; reserved for"},{"line_number":201,"context_line":"            future use when destination checks diverge by migration type"},{"line_number":202,"context_line":"        :returns: list of ComputeNode"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f6cf80a0_ea5e7004","line":199,"range":{"start_line":199,"start_character":0,"end_line":199,"end_character":2},"updated":"2026-06-25 09:26:13.000000000","message":"shouldn\u0027t the source_node always excluded as potential destination? i don\u0027t understand well what is the purpuse of this parameter.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":196,"context_line":""},{"line_number":197,"context_line":"        :param instance: Instance to be migrated"},{"line_number":198,"context_line":"        :param nodes: iterable of ComputeNode candidates"},{"line_number":199,"context_line":"        :param source_node: optional source node to exclude"},{"line_number":200,"context_line":"        :param migration_type: \u0027live\u0027 (default) or \u0027cold\u0027; reserved for"},{"line_number":201,"context_line":"            future use when destination checks diverge by migration type"},{"line_number":202,"context_line":"        :returns: list of ComputeNode"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7ba24bea_1f5e0ec3","line":199,"range":{"start_line":199,"start_character":0,"end_line":199,"end_character":2},"in_reply_to":"f6cf80a0_ea5e7004","updated":"2026-10-08 18:17:54.000000000","message":"it should always be removed yes, but we may want to retrieve information from  the source node, so we can 1) require as parameter, or 2) get direct from the model (it will depend on the implementation and if filter will have access to the model or if will receive just a list of nodes/instance/resources.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":228,"context_line":"  instance UUID listed in ``scheduler_hints[\u0027same_host\u0027]`` is NOT currently"},{"line_number":229,"context_line":"  mapped to this node. All listed instances must be co-located on the"},{"line_number":230,"context_line":"  destination node."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Server group checks are not applied here. Instances belonging to a server"},{"line_number":233,"context_line":"group are excluded entirely by ``filter_instances_for_migration``, so no"},{"line_number":234,"context_line":"server group destination logic is required."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ac201c92_45a87bc9","line":231,"updated":"2026-06-25 09:26:13.000000000","message":"Shouldn\u0027t also check all the relevant options you mentioned in the previous section? numa, pci-passthrough, etc...","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":239,"context_line":"Strategy Refactoring"},{"line_number":240,"context_line":"--------------------"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"The following eight strategies will be updated to call the new base methods:"},{"line_number":243,"context_line":"``workload_balance``, ``workload_stabilization``, ``outlet_temp_control``,"},{"line_number":244,"context_line":"``uniform_airflow``, ``noisy_neighbor``, ``basic_consolidation``,"},{"line_number":245,"context_line":"``vm_workload_consolidation``, and ``node_resource_consolidation``."}],"source_content_type":"text/x-rst","patch_set":1,"id":"35ad59d1_1a274113","line":242,"updated":"2026-06-25 09:26:13.000000000","message":"The filters will be hardcoded methods? I\u0027d suggest to build the filter as an ordered list of discoverable single purpose filters that may be extended or reduced. Also, it may be useful that strategies can enable/disable specific filters when calling the filtering methods.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":239,"context_line":"Strategy Refactoring"},{"line_number":240,"context_line":"--------------------"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"The following eight strategies will be updated to call the new base methods:"},{"line_number":243,"context_line":"``workload_balance``, ``workload_stabilization``, ``outlet_temp_control``,"},{"line_number":244,"context_line":"``uniform_airflow``, ``noisy_neighbor``, ``basic_consolidation``,"},{"line_number":245,"context_line":"``vm_workload_consolidation``, and ``node_resource_consolidation``."}],"source_content_type":"text/x-rst","patch_set":1,"id":"84428ec1_4f0fe1bc","line":242,"in_reply_to":"35ad59d1_1a274113","updated":"2026-10-08 18:17:54.000000000","message":"Agree. The initial proposal should allow to configure the list of filters using watcher.cong (for all audits). After that, the idea is to extend it to support external filter as plugins and also allow users to configure/exclude the filters per audit/audit-template. But maybe this is too much for a single cycle.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":252,"context_line":"because both accept an optional destination node and often delegate destination"},{"line_number":253,"context_line":"selection to the Nova scheduler. The strategy ``saving_energy`` is excluded"},{"line_number":254,"context_line":"because it does not produce migration actions."},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"Alternatives"},{"line_number":257,"context_line":"------------"},{"line_number":258,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"b706a9b6_041451d2","line":255,"updated":"2026-06-25 09:26:13.000000000","message":"Something to consider while using these filters is that previous migrations in the plan may affect suitability of destination hosts, so checking if a destination is valid will require mutate the model when a migration is planned and call the filtering method after each migration added to the solution. This is already the case for strategies which implement allocations-based verification but it may be good to mention.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":252,"context_line":"because both accept an optional destination node and often delegate destination"},{"line_number":253,"context_line":"selection to the Nova scheduler. The strategy ``saving_energy`` is excluded"},{"line_number":254,"context_line":"because it does not produce migration actions."},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"Alternatives"},{"line_number":257,"context_line":"------------"},{"line_number":258,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"11bcd481_19decfc6","line":255,"in_reply_to":"b706a9b6_041451d2","updated":"2026-10-08 18:17:54.000000000","message":"Right, this is a core functionality and we will depend on that I think. strategies will also need to always call model migrate method to update model info, so it will require a small refactoring in some strategies.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":16312,"name":"Alfredo Moralejo","email":"amoralej@redhat.com","username":"amoralej"},"change_message_id":"5181affcc6e23931f692b75e49904ef7ab4cd027","unresolved":true,"context_lines":[{"line_number":270,"context_line":""},{"line_number":271,"context_line":"None. Both new methods operate on instance and node attributes already present"},{"line_number":272,"context_line":"in the CDM. The ``scheduler_hints`` field used by ``filter_destination_nodes``"},{"line_number":273,"context_line":"is provided by a separate blueprint (see Dependencies)."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"REST API impact"},{"line_number":276,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fb8fb0c1_9d53df30","line":273,"updated":"2026-06-25 09:26:13.000000000","message":"In the spec you mention Hypervisor Version Filtering that may need additional information as hypervisor_type, hypervisor_version or compute nodes traits, iiuc.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"0eecf3d1d991d9a978009db4f5688a97a3e5a858","unresolved":true,"context_lines":[{"line_number":270,"context_line":""},{"line_number":271,"context_line":"None. Both new methods operate on instance and node attributes already present"},{"line_number":272,"context_line":"in the CDM. The ``scheduler_hints`` field used by ``filter_destination_nodes``"},{"line_number":273,"context_line":"is provided by a separate blueprint (see Dependencies)."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"REST API impact"},{"line_number":276,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"141fa601_cfe21d3b","line":273,"in_reply_to":"fb8fb0c1_9d53df30","updated":"2026-10-08 18:17:54.000000000","message":"Ack, lets circle back these options once we discuss the design. We can then cover Filter details.","commit_id":"f044bbdfb267cac914af318925bddc4855905419"}],"specs/2027.1/approved/migration-eligibility-filters.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"27cb4a53918920f0acb6203dc5ff105d9aadb1a4","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"1. **BaseStrategy orchestration methods** - Entry points that strategies call"},{"line_number":70,"context_line":"   to filter instances and destinations. Replaces strategy\u0027s code that usually"},{"line_number":71,"context_line":"   retrives all nodes or instances from the model and apply local filtering"},{"line_number":72,"context_line":"   (e.g.: filter out `watcher_exclude` instances)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"2. **FilterManager** - Coordinates filter execution based on a default"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b1e4c0d8_9f6e2d40","line":71,"updated":"2026-10-08 20:01:26.000000000","message":"Five spelling/grammar errors were added to the permanent spec document: line 71 \u0027retrives\u0027 (retrieves); line 115 \u0027Operators can optionally configures which filters are enabled globally\u0027 (configure); line 316 \u0027strateges\u0027 (strategies); line 318 \u0027validade\u0027 (validate); line 372 \u0027especification\u0027 (specification). The intended meaning remains obvious in each case, but the file is published documentation rendered through the docs toctree.\n\n**Severity**: SUGGESTION | **Confidence**: 0.95\n\n**Impact**: The spec is the lasting design reference for the feature and is rendered into the published docs; misspellings reduce document quality and searchability of the design rationale.\n\n**Recommendation**:\nFix the five occurrences: \u0027retrieves\u0027 (line 71), \u0027configure\u0027 (line 115), \u0027strategies\u0027 (line 316), \u0027validate\u0027 (line 318), and \u0027specification\u0027 (line 372). A spell check pass over the file before the next patchset catches all of them.","commit_id":"23fcbdb155f55662ba83a7ee01fc4a9cec4d9b38"},{"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":"27cb4a53918920f0acb6203dc5ff105d9aadb1a4","unresolved":false,"context_lines":[{"line_number":441,"context_line":"Upgrade Impact"},{"line_number":442,"context_line":"--------------"},{"line_number":443,"context_line":""},{"line_number":444,"context_line":"None"},{"line_number":445,"context_line":""},{"line_number":446,"context_line":""},{"line_number":447,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2773960c_40f21625","line":444,"updated":"2026-10-08 20:01:26.000000000","message":"The spec enables all filters by default (line 122) and states that no configuration changes are required for existing deployments (line 433), while its own Problem Description admits that today \u0027locked instances are tracked but never validated\u0027 and not all strategies check watcher_exclude (lines 29-30). Phase 1 refactors workload_stabilization, zone_migration, and host_maintenance to apply every enabled filter, so on upgrade operators get changed migration plans (locked instances and watcher_exclude-marked instances previously eligible are now rejected) with no action on their part, yet the new Upgrade Impact section asserts \u0027None\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Operators reading the spec to plan upgrades will not anticipate that a watcher upgrade silently alters eligibility outcomes for the refactored strategies (e.g. \u0027missing\u0027 migrations of locked instances), complicating upgrade validation and triage of changed audit results.\n\n**Suggestion**:\nRewrite the Upgrade Impact section to state that although no configuration migration is required, the default-enabled filters change eligibility outcomes for the refactored strategies (notably LockedInstanceFilter and consistent watcher_exclude enforcement), and that operators needing the previous behavior can remove the corresponding entries from enabled_instance_filters/enabled_destination_filters.","commit_id":"23fcbdb155f55662ba83a7ee01fc4a9cec4d9b38"},{"author":{"_account_id":30002,"name":"Douglas Viroel","email":"viroel@gmail.com","username":"dviroel"},"change_message_id":"b4431ef7431803edff99a8067696b51694d550b6","unresolved":true,"context_lines":[{"line_number":441,"context_line":"Upgrade Impact"},{"line_number":442,"context_line":"--------------"},{"line_number":443,"context_line":""},{"line_number":444,"context_line":"None"},{"line_number":445,"context_line":""},{"line_number":446,"context_line":""},{"line_number":447,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"74afda9c_88c4a60f","line":444,"in_reply_to":"2773960c_40f21625","updated":"2026-10-08 20:10:31.000000000","message":"Yeah, there might be more strategies that would have their behavior changed with the refactoring, some of them we could even treat as \u0027bugs\u0027.\nIf locked instance always fails to migrate, that could be a limitation/bug","commit_id":"23fcbdb155f55662ba83a7ee01fc4a9cec4d9b38"}]}