redis can't be tested in tf-aws / us-east-1

[skorfmann]

I tried this:

bring cloud;
bring ex;

let redis = new ex.Redis();

test "hello redis" {
  redis.set("hello", "redis");
  assert(redis.get("hello") == "redis");
}

wing test --no-clean -t tf-aws main.w

triggered through winglang/examples#20 (the todo app example)

This happened:

│ Error: creating ElastiCache Cache Cluster: InsufficientCacheClusterCapacity: cache.t4g.small (VPC) is not currently supported in the availability zone us-east-1e.  Retry the launch with no availability zone or target: us-east-1a, us-east-1f, us-east-1b, us-east-1c, us-east-1d.
│ 	status code: 400, request id: e31f9630-7993-4bcb-9225-9415cd1c1ddd
│
│   with aws_elasticache_cluster.Test11axgXYvW8_env0_exRedis_RedisCluster_F35D1C9F,
│   on main.tf.json line 59, in resource.aws_elasticache_cluster.Test11axgXYvW8_env0_exRedis_RedisCluster_F35D1C9F:
│   59:       }
│

I expected this:

it can be tested without errors and without having to worry about availability zones.

note: a normal wing compile -t tf-aws main.w && terraform init / apply works in the same region.

Is there a workaround?

potentially testing in a different region, but haven't tried

Component

SDK

Wing Version

0.29.6

Node.js Version

20.6.0

Platform(s)

MacOS

Anything else?

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

[skorfmann]

summarizing my chat with @staycoolcall911 about why this happens:

Looks like the AWS API is assigning an AZ for the subnet if none was specified:

Default: AWS selects one for you. If you create more than one subnet in your VPC, we do not necessarily select a different zone for each subnet.

In the test case this apparently happens to be the AZ in us-east-1 where that ElastiCache instance type is not available. us-east-1 seems to have 5 or 6 AZs, where other regions usually have 3, sometimes 4.

The docs of ElastiCache aren’t stating anything about limited availability zone support for regions. They are only talking about different instance types in different regions. https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html

In regards to why this is not happening for the "normal" deployment, I don't know. Don't even know if it's working deterministically or just by randomly by accident.

Also, perhaps us-east-1 is a snowflake, and all other regions might be fine? 🤷 Haven't found an API endpoint to check for this.

In any case, might be a good idea fetch availability zones and assign one explicitly to get rid of the AWS randomness.

[skorfmann]

Also, perhaps us-east-1 is a snowflake, and all other regions might be fine? 🤷 Haven't found an API endpoint to check for this.

Ah, it might actually be the generic one https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html

[skorfmann]

Also, perhaps us-east-1 is a snowflake, and all other regions might be fine? 🤷 Haven't found an API endpoint to check for this.

Ah, it might actually be the generic one https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html

Nope :/

 aws ec2  describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=us-east-1a --filters Name=instance-type,Values=cache.t4g.small

=> empty list

[garysassano]

@skorfmann The reason why the deployment fails is because the t4g.small instance type is not available in us-east-1e AZ.

You can generate the above table with the following command:

aws ec2 describe-instance-type-offerings --location-type availability-zone --filters="Name=instance-type,Values=t4g.small" --region us-east-1 --output table

[garysassano]

I will deploy a fix later.

[skorfmann]

@skorfmann The reason why the deployment fails is because the t4g.small instance type is not available in us-east-1e AZ.

ahh, that was the trick 💡 😄

[monadabot]

Congrats! 🚀 This was released in Wing 0.31.5.