ci: move the AWS terraform test roots to AWS provider 6.x - #38695
Conversation
The modules pulled from materialize-terraform-self-managed at main require `hashicorp/aws ~> 6.0` since their provider v6 upgrade, so `terraform init` in these roots has failed on an unsatisfiable constraint since 2026-08-25, taking the AWS E2E and upgrade nightlies with it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Clusters created with EKS module v21 no longer bootstrap the VPC CNI or CoreDNS. With the provider bump the roots got past `terraform init`, but nodes never became Ready and the managed node group failed with `NodeCreationFailure: Unhealthy nodes in the kubernetes cluster` after 33 minutes (nightly 18263). Mirror the modules repository's examples: install the VPC CNI before the base node group and CoreDNS after it, and pass the partition and account id through so the node group plans cleanly despite its depends_on. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
(There is also #38584, which tried to do the same thing.) |
|
Had a look and this looks right to me. Checked it against the modules repo, the additions match I cleaned up the leftover AWS resources, so this should be testable now. Also opened #38721, since the teardown couldn't recover from a failed apply and that's what kept every later run broken. |
|
(Entirely Claude comment) Nightly 18272 (E2E job only, after the cleanup): Cause: with the Teardown: everything was destroyed except what waits on the RDS instance, whose deletion was still running after 55 minutes when the job hit its 90-minute budget (1m51s on 2026-08-24). The account has leftovers again under |
|
Pushed a commit to your branch (hope that's ok, shout if you'd rather I'd opened a separate PR): flipped Your Claude's diagnosis of 18272 was right, I verified each link: apply completes ( Fixing it in the roots rather than upstream because those NetworkPolicies were always there, just inert: before EKS module v21 the bootstrapped CNI had enforcement off, so this is a restore of the previous behaviour rather than a coverage cut. The 6876/6878 gap is still a genuine thing that we will need to look into in CI here but it's beyond this PR. |
Status
Testing is blocked on leftover AWS resources. Nightly 18263 ran the first commit; its apply failed at the managed node group (see below) and the teardown could not delete the EKS clusters while the failed node groups were attached (
ResourceInUseException: Cluster has nodegroups attached, three attempts). Both test prefixes now have half-torn-down environments in account 400121260767, us-east-1:aws-test-dev-eksandaws-up-dev-ekswith theirCREATE_FAILEDnode groups, plus each one's VPC (10 interface endpoints, NAT gateway), KMS key and log group. The harness starts every run from empty state and has no way to adopt or remove leftovers, and the cluster and log-group names are fixed, so a rerun fails within minutes on "already exists". The cloud team has been asked to clean these up; until then the second commit is validated but unexercised on AWS.Motivation
The Nightly Terraform + Helm Chart E2E on AWS and Upgrade jobs have failed at
terraform initon every run since 2026-08-25:The three test roots pin
hashicorp/aws ~> 5.0, while every module they pull from materialize-terraform-self-managed atmainrequires~> 6.0since DEP-200 (MaterializeInc/materialize-terraform-self-managed#390). Terraform resolves one provider version per configuration, so the intersection is empty.Description
Two commits.
awsconstraint to~> 6.0inaws-temporary,aws-upgrade, andaws-persistent. The other provider pins already satisfy the modules' constraints.aws/modules/vpc-cniandkubernetes/modules/corednsmodules. Without them nodes never become Ready and the managed node group fails withNodeCreationFailure: Unhealthy nodes in the kubernetes clusterafter 33 minutes, which is how Nightly 18263 (first commit only) failed. The roots now mirror the examples: VPC CNI before the base node group, CoreDNS after it, thepartitionandaccount_idpassthrough the node-group module asks for when called with adepends_on, and the operator and load-balancer controller depending on CoreDNS.Verification
terraform initandterraform validatepass for all three roots insideci-builder. Nightly 18263 exercised the first commit on a real EKS cluster: init, plan and the apply up to the node group all worked, so the provider bump itself is fine. The two AWS nightly jobs on a Nightly of this branch are the check for the second commit, once the account is clean; the branch name matches their*terraform*/*aws*filter, so a trigger-ci Nightly on it runs both.🤖 Generated with Claude Code
Tracking issue: DEP-245.