[Feature Request] data "aws_ami" - add "allow_empty" flag

[tamsky]

Currently I must match at least one result if I use the "aws_ami" data source.

I would like to implement an A/B lookup of AMI values using the aws_ami data source.
For example, AMI set "A" includes testing AMIs that match a particular environment,
and AMI set "B" includes production AMIs that match all environments.

I would like to be able to select from coalesce(A, B), but to do this today means I must structure my image tags for both AMI lookups to return one result each, and dynamically decide

A != "known-default" ? A : B

Actual Behavior

Null set results in a terraform error and plan phase halts.

Desired Behavior

Null set results in a terraform error only if requested flag allow_empty is false.

[vancluever]

Just saw this issue and thought I'd add a note, as the original author of the aws_ami data source:

My intention of ensuring that there was one single unique result (or the latest AMI) was to protect against a couple of issues:

• Where a search was too broad and, and the AMI that was returned was not the one the user had intended, or
• Where the search ended up returning no results, as more than likely this is not what the user wanted either.

I can definitely see why though, in some scenarios, you might not care if the search returned no AMIs (and especially with the advent of more conditional logic in interpolation - a feature that didn't exist in Terraform when I wrote this), but I think it is potentially dangerous to allow zero results to be returned by the data source.

Having this gated by a flag, like @joshuaspence did in his PR, is a good idea, but I would propose that we go a step further, forgo the flags in aws_ami and aws_ebs_snapshot and instead set up plural-form data sources like we have for aws_autoscaling_groups, aws_availability_zones, etc.

Then, TF config would look like:

data "aws_amis" "ami_search" {
  filter {
    filter data here ....
  }
}

data "aws_ami" "ami_search_results" {
  count = "${data.aws_amis.ami_search.ami_ids}"
  ami_id = "${data.aws_amis.ami_search.ami_ids[count.index]}"
}

This would provide a declaratively semantic way of propagating logic though the graph without having to alter the opinionated nature of the data source.

[apparentlymart]

The approach suggested by @vancluever seems good to me, and consistent with how we addressed a similar use-case for subnets recently.

I would suggest calling the data source aws_ami_ids and its single result attribite ids, since this will then be consistent with aws_subnet_ids and leave room for us to possibly add a new aws_amis data source later if Terraform later gets support for complex-type arrays or some other such feature.

[joshuaspence]

Thanks for the feedback, I've updated my pull request accordingly.

[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.