Skip to content

feat(compute): add c8g Graviton4 machines to the AWS instance catalog (ALIEN-1302) - #923

Merged
lilienblum merged 1 commit into
mainfrom
dan/alien-1302-support-aws-c8g-graviton4-instance-family
Oct 7, 2026
Merged

lilienblum merged 1 commit into
mainfrom
dan/alien-1302-support-aws-c8g-graviton4-instance-family

Conversation

@lilienblum

@lilienblum lilienblum commented Oct 7, 2026 •

Copy link
Copy Markdown
Contributor

Why

AWS c8g (Graviton4) machines give more compute than c7g for a small price increase. Alien rejects them today. plan_compute and ComputeClusterMutation accept only machines in instance_catalog::CATALOG, so a pool set to c8g.2xlarge fails with Unknown aws machine 'c8g.2xlarge'. Alien already runs ARM64 workloads on c7g, m7g, r7g, and t4g, so the catalog entries are the only missing piece.

Scope

  • crates/alien-core/src/instance_catalog.rs adds c8g.medium, c8g.large, c8g.xlarge, c8g.2xlarge, and c8g.4xlarge. This is the same size range as c7g. Each c8g entry follows the c7g entry with the same vCPU count, so test_catalog_instance_types_sorted_by_vcpu_within_family still holds and c7g wins any tie.
  • crates/alien-core/src/compute_planner.rs adds graviton4_compute_machine_can_be_selected.
  • Out of scope are c8g sizes above 4xlarge and the m8g and r8g families.

Blast Radius

select_family never returns ComputeOptimized, so automatic machine selection does not change for any stack. c8g appears only as an explicit choice in the planner's machine options. The CloudFormation generator builds the machine parameter's AllowedValues from those options, so an existing stack offers c8g only after a template update.

Verification

  • graviton4_compute_machine_can_be_selected fails without the catalog entries with ["Unknown aws machine 'c8g.2xlarge' for pool 'general'"], and passes with them.
  • cargo nextest run -p alien-core --lib passes 647 tests. cargo nextest run -p alien-cloudformation passes 147 tests.
  • cfn-lint --regions us-east-1 accepts all five c8g sizes as AWS::EC2::Instance InstanceType values and rejects a made-up c8g.nope.
  • A live deploy ran in a test AWS account in us-east-2, built from this branch, on 2026-10-07:
    • The generated CloudFormation template lists all five c8g sizes in the ComputeGeneralMachine AllowedValues. The planner default for the test workload stays t4g.small.
    • The stack accepted ComputeGeneralMachine=c8g.2xlarge and reached CREATE_COMPLETE. The general pool's autoscaling group launched one c8g.2xlarge with arm64 architecture from the arm64 UEFI machine image.
    • A container workload on that machine returned 2xx on its public HTTPS endpoint. It then converged on a second release on the same pool. The run took 947 seconds.
    • After teardown the stack reports DELETE_COMPLETE, the instance reports terminated, and no autoscaling group or tagged resource with the run prefix remains.

… (ALIEN-1302)

The planner and ComputeClusterMutation accept only catalog machines,
so selecting c8g.2xlarge failed with "Unknown aws machine".
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-07T05:25:32.610490Z fbf1210 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@greptile-apps

greptile-apps Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

RetriggerConfidence Score: 5/5

[Medium risk] Adds new AWS machine types to the instance catalog.

The PR appears safe to merge; no actionable issues were found.

What we checked:

  • Automatic choices stay unchanged: All new entries use ComputeOptimized. select_family never returns that family, so automatic selection does not consider them.
  • x86 pools reject ARM machines: Both machine options and explicit-choice checks use instance_satisfies, which rejects a machine whose architecture differs from the pool’s requirements.

Summary

Adds five ARM64 c8g machines, from c8g.medium through c8g.4xlarge, to the AWS catalog.

  • Adds a planner test for explicitly selecting c8g.2xlarge.
  • Keeps automatic machine selection unchanged.
  • CloudFormation gets the new choices from the planner’s machine options.
  • No actionable issues were found. Tests and live deployment were not run during this review.

Reviews (1) · Last reviewed commit: "feat(compute): add c8g Graviton4 machine..." · Reviewed by Greptile

@lilienblum

Copy link
Copy Markdown
Contributor Author

What was tested, per size:

Size Catalog, planner and template cfn-lint Live deploy
c8g.medium yes yes no
c8g.large yes yes no
c8g.xlarge yes yes no
c8g.2xlarge yes yes yes
c8g.4xlarge yes yes no

The live deploy ran on c8g.2xlarge only. All five sizes use the same arm64 architecture and machine image, so the other four differ only in vCPU and memory.

@lilienblum
lilienblum merged commit 1dce1cb into main Oct 7, 2026
24 checks passed
@lilienblum
lilienblum deleted the dan/alien-1302-support-aws-c8g-graviton4-instance-family branch October 7, 2026 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant