[BUG] Premature validation / run of VE when M&R hasn't processed

[sadsfae]

I am seeing repeated behavior of premature releases in the past where validate_env runs before move_and_rebuild.py is run. This should never happen, we used to hard gate on some host and cloud-level values I believe like provisioned We need to double-check this

Just now I was able to replicate this:

How to Replicate

1. Have move_and_rebuild disabled
2. Have an active schedule on hosts that would have been processed
3. Manually kickstart/clean some hosts on a cloud that would have gone out

Outcomes

1. validate_env runs anyway even though move_and_rebuild has not and passes the cloud prematurely
2. notify.py sends notifiications, cloud is "released"
3. move_and_rebuild.py then runs, pushes cloud back into validating phase
4. cloud re-releases

Functional Example

• Prior to a 10:30 UTC schedule start, cloud36 below had move_and_rebuild disabled as I worked through cleaning some disk cruft left by a previous tenant
• I kickstarted and cleaned the hosts manually
• validate_env kicked off anyway at schedule start time regardless of move_and_rebuild being disabled

=== Validating Started == @  Wed Feb 4 10:30:01 AM UTC 2026
Validating cloud36
You're still within the configurable validation grace period. Skipping validation for cloud36.
Quads assignments validation executed.
=== Validating Finished == @  Wed Feb 4 10:30:05 AM UTC 2026
=== Validating Started == @  Wed Feb 4 10:45:01 AM UTC 2026
Validating cloud36

[sadsfae]

In src/quads/cli/cli.py we might need to add these actions? I haven't checked the defaults when a new assignment is created yet.

def action_cloudresource(self):
        assignment = None
        cloud = None
        data = {
            "cloud": self.cli_args.get("cloud"),
            "description": self.cli_args.get("description"),
            "owner": self.cli_args.get("cloudowner"),
            "ccuser": self.cli_args.get("ccusers"),
            "qinq": self.cli_args.get("qinq"),
            "ticket": self.cli_args.get("cloudticket"),
            "force": self.cli_args.get("force"),
            "wipe": self.cli_args.get("wipe", True),
           + "validated": False,
           +"provisioned": False, 
        }

I am sure why this is set, but also in src/quads/tools/validate_env.py we set the following which could be problematic, though I recall this was there in cases to handle expansions?

https://github.com/redhat-performance/quads/blob/development/src/quads/tools/validate_env.py#L367
https://github.com/redhat-performance/quads/blob/development/src/quads/tools/validate_env.py#L363-L379
https://github.com/redhat-performance/quads/blame/development/src/quads/tools/validate_env.py

    # start by setting any assignment provisioned flag to true if all hosts are validated
    _filter = {"active": True, "validated": False, "provisioned": False, "cloud__ne": "cloud01"}
    assignments = quads.filter_assignments(_filter)
    for _ass in assignments:
        provisioned = True
        _schedules = quads.get_current_schedules(data={"cloud": _ass.cloud.name})
        for _schedule in _schedules:
            if not _schedule.host.validated:
                provisioned = False
                break
        if provisioned:
            quads.update_assignment(
                _ass.id,
                {
                    "provisioned": True,
                },
            )

It appears this was brought in via another fix here: a8ca8a8

[sadsfae]

If my hypothesis is correct here's a potential patch:

diff --git a/src/quads/cli/cli.py b/src/quads/cli/cli.py
index 1234567..89abcdef 100644
--- a/src/quads/cli/cli.py
+++ b/src/quads/cli/cli.py
@@ -1002,6 +1002,8 @@ class QuadsCli:
             "ticket": self.cli_args.get("cloudticket"),
             "force": self.cli_args.get("force"),
             "wipe": self.cli_args.get("wipe", True),
+            "validated": False,
+            "provisioned": False,
         }
         if self.cli_args.get("vlan"):
             try:
diff --git a/src/quads/tools/validate_env.py b/src/quads/tools/validate_env.py
index abcdef1..2345678 100644
--- a/src/quads/tools/validate_env.py
+++ b/src/quads/tools/validate_env.py
@@ -340,23 +340,6 @@ async def main(_args, _logger=None):  # pragma: no cover
     if _logger:
         logger = _logger
 
-    # start by setting any assignment provisioned flag to true if all hosts are validated
-    _filter = {"active": True, "validated": False, "provisioned": False, "cloud__ne": "cloud01"}
-    assignments = quads.filter_assignments(_filter)
-    for _ass in assignments:
-        provisioned = True
-        _schedules = quads.get_current_schedules(data={"cloud": _ass.cloud.name})
-        for _schedule in _schedules:
-            if not _schedule.host.validated:
-                provisioned = False
-                break
-        if provisioned:
-            quads.update_assignment(
-                _ass.id,
-                {
-                    "provisioned": True,
-                },
-            )
 
     _filter = {"active": True, "validated": False, "provisioned": True, "cloud__ne": "cloud01"}
     assignments = quads.filter_assignments(_filter)

I think we want this adjusted at validate_env.py and not instead adjust move_and_rebuild.py to set validated: false and provisoned: false as each tool should focus on their singular job workflows:

• move_and_rebuild = building and provisioning
• validate_env = validating

In this way we handle scenarios in which move_and_rebuild fails to run entirely and removes provisioning logic validate_env.py If we need to fail we want to fail at the first per-requisite move_and_rebuild stage of the allocation workflow.

[sadsfae]

Proposed patch: https://review.gerrithub.io/c/redhat-performance/quads/+/1230581