AWS instructions suggest invalid availability zone

[tomdee]

They say us-west-1c but amazon says Value (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.

[cgag]

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. us-west-1c might map to a different availability zone for me than it does for you.
b) Not all accounts have access to all availability zones. Apparently if an availability zone becomes resource constrained, Amazon will limit its usage to customers who are already there. You can see which availability zones you can use with the aws cli command: aws --region us-west-1 ec2 describe-availability-zones. I only have access to 1a and 1c personally.

From the docs at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones:

An Availability Zone is represented by a region code followed by a letter identifier; for example, us-east-1a. To ensure that resources are distributed across the Availability Zones for a region, we independently map Availability Zones to identifiers for each account. For example, your Availability Zone us-east-1a might not be the same location as us-east-1a for another account. There's no way for you to coordinate Availability Zones between accounts.

As Availability Zones grow over time, our ability to expand them can become constrained. If this happens, we might restrict you from launching an instance in a constrained Availability Zone unless you already have an instance in that Availability Zone. Eventually, we might also remove the constrained Availability Zone from the list of Availability Zones for new customers. Therefore, your account might have a different number of available Availability Zones in a region than another account.

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.

[mumoshu]

@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:

{ "Fn::Select" : [ "0", { "Fn::GetAZs" : { "Ref" : "AWS::Region" }}]}

See my gist for details.

[colhom]

@mumoshu very good point. @cgag what do you think about kube-aws defaulting to selecting a valid AZ in the region if an AZ isn't specified.

[cgag]

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.

[mumoshu]

@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?

• asking user to choose one of available AZs on running kube-aws init with no --availability-zone specified?
• validate and make kube-aws init --availability-zone <UNAVAILABLE_AZ_FOR_YOUR_ACCOUNT> to fail with a message like The availability zone FOO is missing or unavailable in your AWS account. Specify one of: <available AZs here>

I also wonder if a documentation fix would suffice as you mentioned in the prev comment #442 (comment)
Mention in the documentation to run aws ec2 describe-availability-zones for confirming available AZs before proceeding to kube-aws init ?

[robszumski]

@mumoshu Is there a reason that the AZ isn't encoded into the file and is instead passed via flag?

[mumoshu]

@robszumski Excuse me if I'm missing the point.
I guess, in the current implementation, the AZ passed via --availability-zone flag is written to cluster.yaml and eventually encoded into the cfn template.
I believe that we don't need to change this part to improve the UX regarding this issue.

[aaronlevy]

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.