-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws_eip data source missing support for tags #3423
Comments
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? |
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 <notifications@github.com>:
… 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
<#3423 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOEUBtn0ncfGgNb2x9p4wJdbXknn67iks5tVfnKgaJpZM4SIzUd>
.
|
Hey folks, Just as an input, use of Filters ( Relying on map of Tags ( |
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. |
Consistency is nice to have.
Or
Its just confusing, when you can use only in one way. |
@tanzwud unfortunately those two syntaxes are also semantically different. They reflect to different tag capabilities for different AWS API calls. The In my experience the conjunctive |
Until this gets implemented, I'm using an 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.
|
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:
|
Those are great news, thank you @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. |
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! |
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 Configuration Files
Crash Output
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
terraform init
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 sourceThe text was updated successfully, but these errors were encountered: