New resource - aws_availability_zones

[vancluever]

This adds a new resource - aws_availability_zones - to get a list of availability zones that the account/region combination can use.

Precedent: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-getavailabilityzones.html

I've exposed the API parameters (docs in the PR).

One thing - the test is general, as depending on where you are set up, doing something like limiting your region to us-east-1, etc, will give no results. I've tested locally here though with the options and had success.

Also - buildEc2Filters is similar to the function I have in #4396, which I will move to use this if/when things are merged.

[vancluever]

Note the the usefulness of this PR is kind of diminished by the fact that you currently can't splat nested resource attributes. I'd love to see this happen though, and if someone can tell me where to start, I might give it a go.

[radeksimko]

I like the idea, there's a few notes:

• it would be nice if we could limit the amount of zones returned (e.g. not everyone may want to use all 4 AZs in us-east-1, where 2 or 3 AZs would just do the job for cheap redundancy). Maybe introduce limit (TypeInt) would help here?
• it would be nice if we could guarantee the ordering of zones, so that in case I deployed everything into us-east-1a + us-east-1b and API suddenly returns us-east1-a + us-east1-c, I would not suddenly redeploy everything to a different zone. Maybe we can just alphabetically sort the returned list?

Also this resource would hugely benefit from using #4705 when it's a real thing. I wouldn't want to block this PR on any of the above, but I just wanted to note that the linked PR may solve some of the issues users are likely going to hit as they're already hitting it with existing resources, e.g. terraform_remote_state (that works on the same principle).

After all you're probably well aware of that.

[jen20]

I would be tempted to wait on this until #4705 is implemented. I see that @apparentlymart has started work on it, I have some type system work to do in core before turning my attention to it but hopefully it's something we can address soon!

[vancluever]

@radeksimko:

it would be nice if we could limit the amount of zones returned (e.g. not everyone may want to use all 4 AZs in us-east-1, where 2 or 3 AZs would just do the job for cheap redundancy). Maybe introduce limit (TypeInt) would help here?

I think that this might be something we could leave up to the template/module author, no? If you know how many zones you need, then you could just limit your say, count to iterate over that number and leave the rest.

it would be nice if we could guarantee the ordering of zones, so that in case I deployed everything into us-east-1a + us-east-1b and API suddenly returns us-east1-a + us-east1-c, I would not suddenly redeploy everything to a different zone. Maybe we can just alphabetically sort the returned list?

I think this is a good idea for sure. Not too much work, and that way you can expect the same results back all the time. It could be how CloudFormation even behaves, The docs mention a sorted list in the sample results but I'm not too sure if that's just due to the example. I'll add this to the code.

And yeah, I've run into some limitations with these kinds of utility resources for sure in the way they are currently configured. The AMI search resource is kind of resistant to change in that if you change the search parameters it doesn't necessarily update any dependent resources in the next run (although it doesn't affect if the search returns a different AMI, ie: a new AMI is pushed with the same tag, etc). Since this resource is relatively static though, it should be pretty resilient to the shortcomings of the current architecture.

What would benefit this resource much more is if #2833 is addressed, as right now you can't use element on the returned AZs.

[radeksimko]

I think that this might be something we could leave up to the template/module author, no? If you know how many zones you need, then you could just limit your say, count to iterate over that number and leave the rest.

True, that's also an elegant solution. 👍

Either way I think we should wait for #4705

[vancluever]

Roger that. Also, just updated the code - I've simplified the results returned, so now it can be looked up on without having to splat, and also added sorting. Will wait for the LGTM, and/or feedback on if we should just stick with this structure (the value to TF on the other returned values (ie: status and status messages) are kind of debatable), and then will squash.

[josh-padnick]

Is there an update on this PR? This would be a useful feature since I'm still hardcoding availability zone lists into my templates since they vary by AWS account.

[vancluever]

Everyone - it's been a while since this PR is in, and I'm still using it, so I figured I'd give it a rebase to make it easier to merge.

Would love to see this in upstream - even it it gets removed in 0.7 (and again, I would be totally fine with porting it over to a data source when that happens).

[vancluever]

Going to be closing this one shortly, as we have #6805 - going to take the tests from this one and port them over so that we have those.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.