Terraform-provider-aws: aws_eip data source missing support for tags

[hashibot[bot]]

_This issue was originally opened by @MaximF as hashicorp/terraform#17361. It was migrated here as a result of the provider split. The original body of the issue is below._

---

Terraform Version

> terraform -v
Terraform v0.11.3
+ provider.aws v1.9.0

Terraform Configuration Files

data "aws_eip" "sample" {
  tags {
        Name ="A valuable IP"
    }
}

Crash Output

Error: data.aws_eip.sample: : invalid or unknown key: tags

Expected Behavior

Terraform would return an IP with a described "Name" tag value

Actual Behavior

Error: data.aws_eip.sample: : invalid or unknown key: tags

Steps to Reproduce

1. terraform init
2. terraform apply

References

The same issue was fixed for aws_eip resource just over a month ago at hashicorp/terraform#16993.
Now it is a turn for aws_eip data source

[vpadronblanco]

I am currently studying the issue. I wonder if it is best to have a more general 'filter' (which is part of the API), or just use tags. Any thoughts?

[MaximF]

Thanks for a quick response and taking a look into that.
I believe it would be a good start to make tags only support for now. If
someone else requests more functionality - that could be implemented in the
next iteration.

2018-02-16 13:57 GMT-08:00 vpadronblanco [e-mail]:

I am currently studying the issue. I wonder if it is best to have a more
general 'filter' (which is part of the API
https://docs.aws.amazon.com/sdk-for-go/api/service/ec2/#DescribeAddressesInput),
or just use tags. Any thoughts?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/terraform-providers/terraform-provider-aws/issues/3423#issuecomment-366370109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOEUBtn0ncfGgNb2x9p4wJdbXknn67iks5tVfnKgaJpZM4SIzUd
.

[Ninir]

Hey folks,

Just as an input, use of Filters (filter in HCL files) is definitely the way to go here: we already use that in some places like the aws_ami data source, and could use Filter.N from DescribeAddresses as in tag:key=value.
This would be standardised across data sources and would fully rely on the API.

Relying on map of Tags (tags in HCL files) would just confuse users in the end.

[vpadronblanco]

I can leave the tags as complimentary then - something that is available for aws_instance, for example. I saw Richard made some changes to the testing file so once he commits I will commit my changes that accommodate his tests.

[ivankatliarchuk]

Consistency is nice to have.
However, there is support of both types for example

data "aws_subnet_ids" "this" {
    vpc_id = "${xxxxxxx}"

    tags {
      Visibility  = "xxx"
      Environment = "xxxx"
    }
}

Or

data "aws_vpc" "this" {
  default = false

  filter {
    name   = "state"
    values = ["available"]
  }
}

Its just confusing, when you can use only in one way.
Not terraform related, probably. The filter just by tag is preferred in cloud agnostic world.
Is there is a plan for releasing it anywhere in future?
Cheers.

[whereisaaron]

@tanzwud unfortunately those two syntaxes are also semantically different. They reflect to different tag capabilities for different AWS API calls. The tags approach is a conjunctive test (a=x) AND (b=y). Whereas 'filters' approach (maps to AWS filter.N) approach is disjunctive (a=x or y) OR (b=z).

In my experience the conjunctive tags approach is more useful than filters. When only filters are available I sometime have to fashion special tags to represent right combination of properties for which I want to filter.

[PaulColdren]

Until this gets implemented, I'm using an external data provider which calls aws directly. Others may find it useful.

We preallocate EIPs with a separate terraform configuration. In our specific use case, we need durable IPs we can share with customers. Keeping them in a separate terraform configuration makes it easier to mutate the underlying infrastructure without needing to take special precautions to avoid inadvertently releasing the EIPs.

This is how we use the preallocated EIPs from our "main" terraform that actually manages the EC2 instances.

main.tf contents:

data "external" "instance-eip" {
  program = ["${path.module}/get_eip.sh"]

  query {
    name        = "tf-${var.preallocated_eip_name}-eip"
    aws_region  = "${var.aws_region}"
    aws_profile = "${var.aws_account_name}"
  }
}

locals {
  eip_alloc_id = "${data.external.instance-eip.result.allocation_id}"
}

get_eip.sh contents:

#!/usr/bin/env bash

set -uex

eval "$(jq -r '@sh "NAME=\(.name) AWS_REGION=\(.aws_region) AWS_PROFILE=\(.aws_profile)"')"

EIP_QUERY_RESPONSE="$(aws ec2 describe-addresses --region $AWS_REGION --filters "Name=tag:Name,Values=$NAME" --profile $AWS_PROFILE)"

ALLOCATION_ID="$(echo ${EIP_QUERY_RESPONSE} | jq -r '.Addresses[0].AllocationId')"

jq -n --arg allocation_id "$ALLOCATION_ID" '{"allocation_id":$allocation_id}'

[bflad]

Hi folks 👋 Very sorry for the lengthy delays with merging this support, there were a few conflicting pull requests to the same code which needed to get sorted out. Good news is that the following will be supported in version 1.44.0 of the AWS provider, likely releasing later today or tomorrow:

• Search by filter
• Search by tags
• EC2-Classic support

[MaximF]

Those are great news, thank you @bflad!

[bflad]

This has been released in version 1.44.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!