-
Notifications
You must be signed in to change notification settings - Fork 467
AWS instructions suggest invalid availability zone #442
Comments
I just looked into this a bit since we use us-west-1c a fair amount and it turns out out that: a) The meaning of us-west-1c varies between accounts. From the docs at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones:
I'm not sure how we should change the docs to reflect that possibility. The error message seems pretty helpful, but maybe we should make a note that it might fail and to choose another availability zone if it does. |
@cgag Just a thought but if we like to automate things as much as possible, I guess we can let CloudFormation choose the first availability zone available to an user using something like this in templates:
See my gist for details. |
It sounds like a nice UX to me, but I don't know how important being in a particular AZ is likely to be to people. If people are likely to significantly regret accepting some default AZ in the future, it might be good to force them to think about it. |
@cgag I agree with you about forcing users to think about AZ they choose. @colhom @cgag In my random idea, does any of follows make sense to you?
I also wonder if a documentation fix would suffice as you mentioned in the prev comment #442 (comment) |
@mumoshu Is there a reason that the AZ isn't encoded into the file and is instead passed via flag? |
@robszumski Excuse me if I'm missing the point. |
The kube-aws tool has been moved to its own top-level directory @ https://github.com/coreos/kube-aws If this issue still needs to be addressed, please re-open the issue under the new repository. |
They say
us-west-1c
but amazon saysValue (us-west-1c) for parameter availabilityZone is invalid. Subnets can currently only be created in the following availability zones: us-west-1b, us-west-1a.
The text was updated successfully, but these errors were encountered: