feat(preflights): allow same-architecture AWS machine changes at runtime

[ItamarZand88]

Summary

On AWS, a ComputeCluster capacity group can now move to another machine of the same CPU architecture (for example t4g.micro to t4g.small) as an ordinary update instead of a setup rerun. Cross-architecture changes, unknown machines, and GCP and Azure still require setup.

When a deployment update changes a capacity group's machine type:

1. The Frozen compatibility check compares the installed ComputeCluster with the new one.
2. On AWS it accepts a machine change when both machines are in the catalog with the same architecture, and the new profile is one the compute mutation could produce for that machine. ← the change
3. The executor's ComputeCluster::validate_update allows the same pair, so the update is planned and the runtime controller rolls the fleet.

This PR changes a same-architecture AWS machine change from "rerun setup" to a runtime update.

What was broken

ComputeCluster is Frozen: setup owns it, and runtime may only change capacity (counts and autoscale bounds). Any machine-type change failed the Frozen check with DEPLOYMENT_SETUP_REQUIRED, and validate_update rejected it as immutable, even though setup creates no launch template or autoscaling group. The fleet is the runtime's to manage, and an arm64-to-arm64 change needs no new identity, network or image.

What I did

• frozen_resources_unchanged.rs: runtime_managed_frozen_change takes the platform. On AWS it also normalizes a group's instance_type and profile when:
  • both machines are in the AWS catalog with the same architecture;
  • the profile matches the catalog (CPU, memory, GPU, architecture) and its disk is what the compute mutation produces with the workload's request unchanged: a configurable disk keeps the installed size; moving off a fixed disk, the catalog disk grown to the containers' request, no larger than the installed disk; a fixed-disk target at its catalog size, covering the request;
  • nested virtualization is only kept on a machine that supports it.
    Any other group, profile, placement or networking change still needs setup.
• instance_catalog.rs: is_same_architecture_aws_machine(old, new).
• compute_cluster.rs: validate_update accepts an unchanged name or a same-architecture AWS pair. Its error says what is allowed instead of "immutable". The doc comment says setup owns identity and network and runtime manages the fleet. Generated schemas updated with pnpm -C packages/core generate.
• updating.rs: comment on which Frozen resources the runtime may reconcile.

Files touched

• crates/alien-preflights/src/compatibility/frozen_resources_unchanged.rs
• crates/alien-core/src/instance_catalog.rs
• crates/alien-core/src/resources/compute_cluster.rs
• crates/alien-deployment/src/updating.rs
• packages/core/src/generated/schemas/computeCluster.json, packages/core/src/generated/zod/compute-cluster-schema.ts (generated)
• Tests: crates/alien-preflights/tests/compute_machine_change.rs, crates/alien-preflights/src/runner.rs, crates/alien-infra/src/core/executor_tests/update_tests.rs, plus unit tests in the files above.

How I tested

• Manually, real AWS: I deployed a container app on t4g.micro, changed the pool to t4g.small through a deployment update, and watched the fleet roll in about 4.5 minutes with the endpoint answering 200 throughout; the update succeeded. Then I tore it down.
• Unit and integration tests:
  • Frozen check: a same-architecture change passes, with new bounds too; cross-architecture, unknown or removed machines, GCP and Azure, a profile change without a machine change, and forged profiles (architecture, CPU, memory, GPU, disk) need setup; a disk grown or shrunk with the machine change needs setup; fixed-disk moves follow the containers' request within the installed disk, with or without a recorded profile; a fixed-disk target must cover the request; a nested-virtualization group moves only to a capable machine.
  • The preflight runner clears a resize and a same-architecture change on the installed platform and refuses arm64 to x86_64.
  • The executor plans a same-architecture update and refuses a cross-architecture one with RESOURCE_CONFIG_INVALID.
  • cargo test for alien-core (616), alien-preflights with runtime-checks (393 + integration, including real compute-mutation output for an i4i.xlarge to m7i.large move), alien-deployment (147+) and the alien-infra executor tests (123) pass.
• Anything I couldn't test: whether the generated TypeScript schema change matters to any consumer beyond the description text (it is description-only).

[greptile-apps]

Confidence Score: 5/5

[High risk] Allows runtime machine type changes on AWS within same CPU architecture.

The PR appears safe to merge based on the reviewed changes.

Summary

The PR permits same-architecture AWS ComputeCluster machine changes through the Frozen compatibility check and update validation, while retaining setup requirements for other machine changes. The latest revision derives an installed group’s disk from its catalog machine when its profile is missing and checks that a fixed-disk target covers the matched workload request.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Machine change] --> B{AWS catalog machines<br/>same architecture?}
  B -- No --> C[Setup required]
  B -- Yes --> D{Target profile and<br/>storage checks pass?}
  D -- No --> C
  D -- Yes --> E[Runtime fleet update]

Loading

_{Reviews (6) · Last reviewed commit: "fix(preflights): read a fixed disk from ..."}