AWS spaces include fan subnets causing deploys to fail until a non-fan subnet is found

When I deploy on AWS [0] my juju status displays a message:

failed to start machine 1 in zone "us-west-2a", retrying in 10s with new availability zone: The subnet ID 'subnet-e8ef17a0-INFAN-172-31-102-0-24' does not exist (InvalidSubnetID.NotFound)

see [1]

The message changes and displays the error for each of the fan subnets until it moves on and finds an AWS subnet and eventually deploys an instance.

I can see the fan subnets when I list juju spaces [2], not sure if this is intended or not.

Can we discuss a better user facing way of displaying this information, or possibly skip iterating over the fan nets?

[0] juju deploy cs:~omnivector/redis redis-data --constraints "spaces=nat"
[1] Ubuntu Pastebin
[2] Ubuntu Pastebin

I think it is very much the intent to show the fan subnet in “juju subnets” because if you deploy containers, they will be accessible in that space. However, I agree that we shouldn’t use them as targets for deployment.

1 Like